Diseño de un módulo de autenticación de usuario (Roles y derechos)

Estoy tratando de modelar un módulo de autenticación de usuario para una base de datos MS SQL Server que será el back-end de una aplicación de interfaz de usuario de Delphi. Básicamente, quiero tener cuentas de usuario donde el usuario pertenece a un solo grupo. Un grupo puede tener "n" número de derechos.

También quiero agregar el historial de contraseñas a la base de datos, ya que el usuario deberá cambiar su contraseña en función de la configuración de la aplicación (por ejemplo, cada 90 días).

También quiero registrar un evento cada vez que un usuario inicia y cierra sesión. Puedo extender esto a eventos adicionales en el futuro.

A continuación encontrarás mi primer crack. Por favor, hágame saber cualquier sugerencia para mejorarlo, ya que esta es la primera vez que hago esto.

¿Ve alguna necesidad de atributos adicionales para la seguridad basada en roles y restricciones para las reglas de contraseña / períodos de caducidad?

Según sus requisitos establecidos, su modelo está en muy buena forma.

Aquí hay algunas sugerencias para mejorar:

• No lo dices explícitamente, por lo que es difícil decirlo, pero parece que podrías estar almacenando la contraseña de usuario directamente. ¡Esto sería muy malo! Si observa bases de datos de autenticación comunes, las contraseñas se almacenan en forma cifrada. A menudo ves tanto una passwordcolumna como una password_saltcolumna.

• Tu USER_LOGSmesa tiene una Eventcolumna. No tienes claro cómo se debe poblar. ¿Debería haber una EVENT_TYPEtabla que USER_LOGShaga referencia? Esto podría generar informes más amigables. Los eventos típicos incluyen inicio de sesión, cierre de sesión, falla de contraseña, cambio de contraseña, restablecimiento de contraseña, bloqueo, desbloqueo, ...

• Su GROUP_RIGHTStabla no indica quién otorgó los derechos. Para fines de auditoría, las personas a menudo mantienen un registro de quién cambió qué registro y cuándo. Eso puede no ser un problema para usted.

Aquí hay un par de preguntas sobre sus requisitos comerciales establecidos, que difieren del patrón de seguridad basado en roles del "libro de texto" de varias maneras:

• ¿Estás seguro de que quieres que los usuarios estén en un solo grupo? La ventaja de la seguridad basada en roles es que los roles tienden a ser bastante estáticos, mientras que las personas que cumplen roles van y vienen con bastante frecuencia. Se incluye en esto que algunas personas a menudo "usan dos sombreros".

• Su diseño es solo de subvención. Algunos sistemas incluyen otorgar y revocar . Esto le permite decir que un derecho ampliamente disponible no está disponible para un grupo en particular.

• Tienes usuarios y cuentas como USERSen tu diseño. A menudo hay una distinción entre las personas y las ID de usuario . Algunas ID de usuario son para equipos o máquinas y algunas personas tienen ID de usuario múltiples para diferentes propósitos. ¿Es esta una distinción que te sería útil?

Creo que los operadores bit a bit son la mejor manera de implementar el permiso del usuario. Aquí estoy mostrando cómo podemos implementarlo con Mysql.

A continuación se muestran tablas de muestra con algunos datos de muestra:

Tabla 1 : Tabla de permisos para almacenar el nombre del permiso junto con un 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 la identificación de usuario, nombre y rol. El rol se calculará como la suma de los permisos.
Ejemplo:
si el usuario 'Ketan' tiene permiso de 'User-Add' (bit = 1) y 'Blog-Delete' (bit-64), el rol será 65 (1 + 64).
Si el usuario 'Mehata' tiene permiso de 'Blog-View' (bit = 128) y 'User-Delete' (bit-4), 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');

Alojar permiso del usuario Después de iniciar sesión si queremos 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 de 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