Los permisos para realizar determinadas operaciones se asignan a roles específicos.
Dado que los usuarios no reciben permisos directamente, sino que sólo los adquieren a través de su rol (o roles), la gestión de los derechos de los usuarios individuales se reduce a asignar los roles apropiados a la cuenta del usuario; lo que simplifica las operaciones comunes como agregar un usuario o cambiarle de departamento.
Se definen tres reglas principales para RBAC: También pueden aplicarse restricciones adicionales, y los roles se pueden combinar en una jerarquía donde los roles de nivel superior incluyen los permisos de los sub-roles.
[7] DAC con grupos (por ejemplo, como se implementa en sistemas de archivos POSIX) puede emular RBAC.
Por ejemplo, una ACL podría usarse para conceder o denegar acceso de escritura a un archivo del sistema en particular, pero no dictaría cómo podría cambiarse ese archivo.
En un sistema basado en RBAC, una operación podría consistir en "crear una cuenta de crédito" en una aplicación financiera o "registrar un nivel de azúcar en sangre" en una aplicación médica.
Se han analizado las condiciones necesarias y suficientes para la seguridad de SoD en RBAC.
Un principio subyacente de SoD es que ningún individuo debería poder violar la seguridad mediante un doble privilegio.
El control de acceso basado en relaciones o ReBAC es un modelo que evoluciona desde RBAC.
Las aplicaciones para compartir claves dentro de entornos virtualizados dinámicos han mostrado cierto éxito al abordar este problema.