Control de acceso basado en permisos frente a permisos

38

Estoy tratando de entender el compromiso inherente entre roles y permisos cuando se trata del control de acceso (autorización).

Comencemos con un dado: en nuestro sistema, un Permiso será una unidad de acceso detallada (" Editar recurso X ", " Acceso la página del panel de control ", etc.). Un Role será una colección de 1+ Permissions. Un usuario puede tener 1+ roles. Todas estas relaciones (usuarios, roles, permisos) se almacenan en una base de datos y se pueden cambiar sobre la marcha y según sea necesario.

Mis preocupaciones:

  

(1) ¿Qué tiene de malo el control de los roles para el control de acceso? ¿Qué beneficios se obtienen al verificar los permisos? En otras palabras, ¿cuál es la diferencia entre estos dos fragmentos de código a continuación:

if(SecurityUtils.hasRole(user)) {
    // Grant them access to a feature
}

// vs.
if(SecurityUtils.hasPermission(user)) {
    // Grant them access to a feature
}

Y:

  

(2) En este escenario, ¿qué valor útil proporcionan los roles? ¿No podríamos simplemente asignar los permisos 1+ a los usuarios directamente? ¿Qué valor concreto de la abstracción ofrecen los roles (alguien puede dar ejemplos específicos)?

    
pregunta smeeb 13.10.2015 - 10:28

2 respuestas

56
  

(1) ¿Qué tiene de malo el control de los roles para el control de acceso? Qué   ¿Se obtienen beneficios al verificar los permisos?

En el momento de la comprobación, el código de llamada solo necesita saber "¿el usuario X tiene permiso para realizar la acción Y?" . Al código que llama no le importa y no debe ser consciente de las relaciones entre roles y permisos.

La capa de autorización luego verificará si el usuario tiene este permiso, generalmente verificando si la función del usuario tiene este permiso. Esto le permite cambiar la lógica de autorización sin actualizar el código de llamada.

Si verifica directamente la función en el sitio de la llamada, está formando implícitamente relaciones de permiso de función e inyectando la lógica de autorización en el código de llamada, violando la separación de preocupaciones.

Si posteriormente decide que el rol foo no debería tener el permiso baz , tendría que cambiar cada código que verifique si el usuario es un foo .

  

(2) En este escenario, ¿qué valor útil proporcionan los roles? No podría   ¿Simplemente asignamos los permisos 1+ a los usuarios directamente? Que valor concreto   de la abstracción ofrecen los roles (¿alguien puede dar ejemplos específicos)?

Los roles representan conceptualmente una colección de permisos con nombre.

Supongamos que está agregando una nueva función que le permite a un usuario editar ciertas configuraciones. Esta función debería estar disponible solo para administradores.

Si está almacenando permisos por usuario, tendría que encontrar a todos los usuarios en su base de datos que, de alguna manera, sabe que son administradores (Si no está almacenando información de roles para los usuarios, ¿cómo sabría incluso qué usuarios son ¿Administradores?) , y agregue este permiso a su lista de permisos.

Si usa roles, solo tiene que agregar el permiso al rol Administrator , que es más fácil de realizar, más eficiente en espacio y es menos propenso a errores.

    
respondido por el Rotem 13.10.2015 - 11:07
16

En respuesta a su primera pregunta, el mayor problema con la verificación de que un usuario tiene un rol en lugar de un permiso específico, es que los permisos pueden ser mantenidos por múltiples roles. Como ejemplo de esto, un desarrollador puede tener acceso para ver el portal de desarrolladores en la intranet de la empresa, que probablemente también sea un permiso que tiene su gerente. Si un usuario intenta acceder al portal de desarrolladores, tendrá una comprobación similar a:

if(SecurityUtils.hasRole(developer)) {
    // Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
    // Grant them access to a feature
} else if...

(Una declaración switch en su idioma de elección sería mejor, pero no particularmente ordenada)

Cuanto más común o general sea un permiso, mayor será el número de roles de usuario que necesitaría verificar para garantizar que alguien pueda acceder a un sistema determinado. Esto también provocaría el problema de que cada vez que modifique los permisos para un rol, deberá modificar la comprobación para reflejar esto. En un sistema grande, esto sería muy difícil de manejar muy rápidamente.

Si simplemente verifica que el usuario tenga el permiso que le permite acceder al portal de desarrolladores, por ejemplo, no importa el rol que tengan, se le otorgará acceso.

Para responder a su segunda pregunta, la razón por la que tiene roles es porque actúan como fáciles de modificar y distribuir "paquetes" de permisos. Si tiene un sistema que tiene cientos de roles y miles de permisos, agregar un nuevo usuario (por ejemplo, un nuevo gerente de RRHH) le exigirá que los apruebe y le otorgue cada uno de los permisos que tienen otros gerentes de RRHH. Esto no solo sería tedioso, sino que también es propenso a cometer errores si se hace manualmente. Compare esto simplemente agregando el rol de "administrador de recursos humanos" al perfil de un usuario, lo que les otorgará el mismo acceso que cualquier otro usuario con ese rol.

Podría argumentar que simplemente podría clonar un usuario existente (si su sistema lo admite), pero si bien esto le otorga al usuario los permisos correctos para ese momento, intentando agregar o eliminar un permiso para todos los usuarios en el El futuro puede ser difícil. Un ejemplo de esto es si tal vez en el pasado el personal de Recursos Humanos también estaba a cargo de la nómina, pero más adelante la compañía se vuelve lo suficientemente grande como para contratar personal específicamente para manejar la nómina. Esto significa que HR ya no necesita acceder al sistema de nómina, por lo que se puede eliminar el permiso. Si tiene 10 miembros diferentes de Recursos Humanos, deberá pasar manualmente y asegurarse de eliminar el permiso correcto, lo que presenta la posibilidad de un error de usuario. El otro problema con esto es que simplemente no se escala; a medida que gana más y más usuarios en un rol dado, la modificación de un rol es mucho más difícil. Compare esto con el uso de roles, donde solo tendría que modificar el rol general en cuestión para eliminar el permiso, que se reflejaría en cada usuario que tenga ese rol.

    
respondido por el Matt Champion 13.10.2015 - 11:14

Lea otras preguntas en las etiquetas