Projetando um Módulo de Autenticação do Usuário (Funções e Direitos)

Estou tentando modelar um módulo de autenticação de usuário para um banco de dados do MS SQL Server que será o back-end de um aplicativo de interface do usuário Delphi. Basicamente, quero ter contas de usuário em que o usuário pertença a apenas um grupo. Um grupo pode ter "n" número 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 de aplicativo (por exemplo, a cada 90 dias).

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

Abaixo você encontrará minha primeira rachadura. Por favor, deixe-me saber algumas sugestões para melhorá-lo, pois esta é minha primeira vez fazendo 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 validade?

Com base nos requisitos estabelecidos, seu modelo está em boas condições.

Aqui estão algumas sugestões para melhorias:

• Você não diz isso explicitamente, por isso é 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 serão armazenadas em forma criptografada. Você costuma ver uma passwordcoluna e uma password_saltcoluna.

• Sua USER_LOGStabela tem uma Eventcoluna. Você não tem certeza de como isso deve ser preenchido. Deve haver uma EVENT_TYPEtabela que USER_LOGSfaça referência? Isso pode gerar relatórios mais amigáveis. Eventos típicos incluem logon, 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 os requisitos comerciais estabelecidos, que diferem do padrão de segurança baseado em funções do "livro de texto" de duas 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 bem estáticas, enquanto as pessoas que desempenham funções vêm e vão com bastante frequência. Incluído nisso é que algumas pessoas costumam "usar dois chapéus".

• Seu design é apenas de 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 disponíveis como USERSno seu design. Geralmente, 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 propósitos diferentes. Essa distinção seria útil para você?

Eu 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 amostra com alguns dados de amostra:

Tabela 1 : Tabela de permissões para armazenar o nome da permissão juntamente com o bit 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 amostra 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 do usuário para armazenar a identificação do usuário, nome e função. 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), a função será 65 (1 + 64).
Se o usuário 'Mehata' tiver permissão de 'Visualização do blog' (bit = 128) e 'Excluir usuário' (bit-4), a função 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 permissão 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 fornecerá saída como -

User-Add - 1
Blog-Delete - 64

Se quisermos verificar o clima, um usuário específico tem permissão de edição 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