usuarios - roles y privilegios en mysql

¿Mejores prácticas para diseñar roles de usuario y sistema de permisos?

Question

Necesito agregar roles de usuario y sistema de permisos a mi aplicación web creada usando PHP / MySQL. Quiero tener esta funcionalidad:

1. Un usuario root puede crear subraíces, grupos, reglas y usuarios normales (todos los privilegios).
2. Las raíces secundarias solo pueden crear reglas, permisos y usuarios para su propio grupo (sin grupos).
3. Un usuario puede acceder al contenido creado por él o por su grupo, según el permiso que se le haya asignado, por grupo raíz.

Necesito que el sistema sea lo suficientemente flexible para que los nuevos roles y permisos se asignen al contenido.

Tengo una tabla de users almacena la clave del grupo junto con otra información. Actualmente estoy usando dos feilds en cada tabla de contenido, es decir, createdBy y CreatedByGroup , y lo uso como el punto de si un determinado usuario tiene permisos. Pero no es lo suficientemente flexible, porque para cada nuevo contenido, tengo que ir a través de todas las actualizaciones de datos y permisos. Por favor, ayúdenme discutiendo sus mejores prácticas para el diseño de esquemas.

Answer 1

Creo que el operador bit a bit es la mejor manera de implementar el permiso del usuario. Aquí estoy mostrando cómo podemos implementarlo con MySQL.

A continuación se muestra una tabla de muestra con algunos datos de muestra:

Tabla 1 : Tabla de permisos para almacenar el nombre del permiso junto con bit como 1, 2, 4, 8 .. etc. (múltiplo de 2)

CREATE TABLE IF NOT EXISTS `permission` (
`bit` int(11) NOT NULL,
`name` varchar(50) NOT NULL,
PRIMARY KEY (`bit`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Inserte algunos datos de muestra en la tabla.

INSERT INTO `permission` (`bit`, `name`) VALUES
(1, ''User-Add''),
(2, ''User-Edit''),
(4, ''User-Delete''),
(8, ''User-View''),
(16, ''Blog-Add''),
(32, ''Blog-Edit''),
(64, ''Blog-Delete''),
(128, ''Blog-View'');

Tabla 2 : tabla de usuario para almacenar ID de usuario, nombre y función. El rol se calculará como la suma de permisos.
Ejemplo:

Si el usuario ''Ketan'' tiene permiso de ''User-Add'' (bit = 1) y ''Blog-Delete'' (bit-64), entonces la función será 65 (1 + 64).
Si el usuario ''Mehata'' tiene permiso de ''Blog-View'' (bit = 128) y ''User-Delete'' (bit-4), entonces el rol será 132 (128 + 4).

CREATE TABLE IF NOT EXISTS `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(50) NOT NULL,
`role` int(11) NOT NULL,
`created_date` datetime NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Data de muestra-

INSERT INTO `user` (`id`, `name`, `role`, `created_date`)
VALUES (NULL, ''Ketan'', ''65'', ''2013-01-09 00:00:00''),
(NULL, ''Mehata'', ''132'', ''2013-01-09 00:00:00'');

Permiso de alojamiento del usuario Después de iniciar sesión si deseamos cargar el permiso del usuario, podemos consultar a continuación para obtener los permisos:

SELECT permission.bit,permission.name
FROM user LEFT JOIN permission ON user.role & permission.bit
WHERE user.id = 1

Aquí user.role "&" permission.bit es un operador Bitwise que dará salida como -

User-Add - 1
Blog-Delete - 64

Si queremos verificar el clima, un usuario en particular tiene permiso de edición del usuario o no-

 SELECT * FROM `user`
WHERE role & (select bit from permission where name=''user-edit'')

Salida = Sin filas.

También puedes ver: http://goo.gl/ATnj6j

Answer 2

El patrón que se adapta a sus necesidades se llama control de acceso basado en roles .

Hay varias implementaciones buenas en PHP, incluyendo Zend_Acl (buena documentación), phpGACL y TinyACL . La mayoría de los marcos también tienen sus propias implementaciones de una LCA de alguna forma.

Incluso si elige rodar el suyo, lo ayudará a revisar soluciones bien factorizadas como esas.

Answer 3

Es posible que no quieras grupos de permisos. En su lugar, cree grupos de usuarios, conceda permisos a los grupos de usuarios y coloque a los usuarios en grupos. Los usuarios también deben poder anular los permisos de los grupos en los que se encuentran. Denegar siempre debe anular la concesión cuando un usuario se encuentre en más de un grupo con el permiso.

En resumen:

• El usuario tiene cero o más permisos (grany, deny)
• El usuario está en cero o más grupos
• El grupo tiene cero o más permisos (otorgar, denegar)

Answer 4

Tenía una estructura ligeramente diferente, pero debería poder servir como referencia.

Cada usuario tiene asociado un "Rol", un "ID de grupo" y una tabla de grupo a la que hace referencia el ID de grupo. Entonces tengo 3 tabla de permisos.

PermissionMaster(FormName)

PermissionChild(PermissionMasterID, PermissionName, Desc, DefaultValue, DependOn) y

PermissionGroupChild(GroupID, PermissionChildID, Allow)

PermissionMaster posee el nombre / formulario / módulo al que se refiere el permiso. PermissionChild mostrará una lista de todos los permisos posibles disponibles para cada maestro, como ''Crear'', ''Ver'', ''Editar'', ''Eliminar'' y la descripción (No tuve esto en la primera versión, y comenzó a ser confuso cuando hay demasiadas configuraciones de permisos incluso para 1 módulo). Permito agregar más niños para referirme específicamente a alguna función como ''ChangeTimeStamp'', que también permitiría permisos más específicos y luego ''Editar''

Entonces PermissionGroupChild es el enlace entre la tabla PermissionChild y Group. Cada grupo tendrá un conjunto de PermissionChild copiado y configurado con la configuración predeterminada. Luego tuve una clase de permiso que hace la consulta de la tabla y verifica para cada usuario. Solo lo cargo durante el inicio de sesión. Luego, en cada formulario / módulo, verifico si es el permiso apropiado y aplica la UI correctamente.

En cuanto a la función, solo la utilizo en la página de configuración de inicio de sesión. El valor de rol más pequeño significa más alto. De modo que el usuario solo puede verse a sí mismo y a aquellos con un valor de Rol superior a sí mismo. Él / ella puede editar los de rango inferior a sí mismo, pero no similar.

Answer 5

Tengo grupos y usuarios (como la solución LDAP de Active Directory). Entonces, si doy acceso al grupo, necesito que los usuarios de este grupo tengan acceso herido.

Entonces, basado en la respuesta @ suresh-kamrushi a continuación, hice esto:

INSERT INTO `permission` (`bit`, `name`) VALUES
(1, ''add-yes''),
(2, ''add-no''),
(4, ''edit-yes''),
(8, ''edit-no''),
(16, ''del-yes''),
(32, ''del-no''),
(64, ''view-yes''),
(128, ''view-no'');

Si el usuario tiene el bit 00000000 , tomo los primeros dos dígitos 00 que significan add-yes y add-no heredados de los permisos del grupo.

Si el usuario tiene el bit 01010110 , tomo los primeros dos dígitos 01 que significan que add-no 01010110 permisos del grupo, por lo que este usuario no tiene permiso de agregar. Este bitwise dice que el usuario solo puede ver.

También está trabajando con grupos de padres.

¿Qué piensas de esta solución? ¿Alguien tiene una mejor manera para eso?