Início / dba / Perguntas / 22837
Accepted
Johnny Holmes
Asked: 2012-08-22 07:21:05 +0800 CST

Projetando um módulo de autenticação de usuário (Funções e direitos)

  • 772

Estou tentando modelar um módulo de autenticação de usuário para um banco de dados MS SQL Server que será o back-end de um aplicativo Delphi UI. Basicamente, quero ter contas de usuário em que o usuário pertença a apenas um grupo. Um grupo pode ter um número "n" de direitos.

Também quero adicionar o histórico de senhas ao banco de dados, pois o usuário precisará alterar sua senha com base em uma configuração do aplicativo (por exemplo, a cada 90 dias).

Eu também quero registrar um evento para cada vez que um usuário fizer login e logout. Posso estender isso para eventos adicionais no futuro.

Abaixo você encontrará meu primeiro crack nele. Por favor, deixe-me saber quaisquer sugestões para melhorá-lo, pois esta é a primeira vez que faço isso.

Você vê alguma necessidade de atributos adicionais para segurança baseada em função e restrições para as regras de senha/períodos de expiração?

db-design

database-design datatypes

2 respostas

  1. Best Answer

    Com base em seus requisitos declarados, seu modelo está em boa forma.

    Seguem algumas sugestões de melhoria:

    • Você não diz isso explicitamente, então é difícil dizer - mas parece que você pode estar armazenando a senha do usuário diretamente. Isso seria muito ruim! Se você observar os bancos de dados de autenticação comuns, as senhas são armazenadas de forma criptografada. Muitas vezes você vê uma passwordcoluna e uma password_saltcoluna.

    • Sua USER_LOGStabela tem uma Eventcoluna. Você não está claro sobre como isso deve ser preenchido. Deve haver uma EVENT_TYPEtabela que USER_LOGSreferencia? Isso pode tornar os relatórios mais amigáveis. Eventos típicos incluem login, logout, falha de senha, alteração de senha, redefinição de senha, bloqueio, desbloqueio, ...

    • Sua GROUP_RIGHTStabela não indica quem concedeu os direitos. Para fins de trilha de auditoria, as pessoas geralmente mantêm um registro de quem alterou qual registro e quando. Isso pode não ser um problema para você.

    Aqui estão algumas perguntas sobre seus requisitos de negócios declarados, que diferem do padrão de segurança baseado em função do "livro de texto" de algumas maneiras:

    • Tem certeza de que deseja que os usuários estejam em apenas um grupo? A vantagem da segurança baseada em funções é que as funções tendem a ser bastante estáticas, enquanto as pessoas que as cumprem vêm e vão com bastante frequência. Incluído nisso é que algumas pessoas costumam "usar dois chapéus".

    • Seu design é apenas para concessão. Alguns sistemas incluem concessão e revogação . Isso permite que você diga que um direito amplamente disponível não está disponível para um grupo específico.

    • Você tem usuários e contas combinados como USERSem seu projeto. Muitas vezes há uma distinção entre pessoas e IDs de usuário . Alguns IDs de usuário são para equipes ou máquinas e algumas pessoas têm vários IDs de usuário para diferentes propósitos. Esta é uma distinção que seria útil para você?

    • 12

  2. Acho que o operador bit a bit é a melhor maneira de implementar a permissão do usuário. Aqui estou mostrando como podemos implementá-lo com o Mysql.

    Abaixo está uma tabela de exemplo com alguns dados de exemplo:

    Tabela 1 : Tabela de permissões para armazenar o nome da permissão junto com o 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;

    Insira alguns dados de exemplo na tabela. 

    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');

    Tabela 2 : Tabela de usuários para armazenar id, nome e função do usuário. A função será calculada como a soma das permissões.
    Exemplo:
    Se o usuário 'Ketan' tiver permissão de 'User-Add' (bit=1) e 'Blog-Delete' (bit-64) então o papel será 65 (1+64).
    Se o usuário 'Mehata' tiver permissão de 'Blog-View' (bit=128) e 'User-Delete' (bit-4) então o papel 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;

    Dados de amostra-

    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');

    Permissão de carregamento do usuário Após o login, se quisermos carregar a permissão do usuário, podemos consultar abaixo para obter as permissões:

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

    Aqui user.role "&" permission.bit é um operador Bitwise que dará saída como -

    User-Add - 1
Blog-Delete - 64

    Se quisermos verificar se um usuário específico tem permissão de edição de usuário ou não-

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

    Saída = Sem linhas.

    Você pode ver também: http://goo.gl/ATnj6j

    • 3

relate perguntas