web-dev-qa-db-fra.com

Conception d'un module d'authentification utilisateur (rôles et droits)

J'essaie de modéliser un module d'authentification utilisateur pour une base de données MS SQL Server qui sera le back-end d'une application d'interface utilisateur Delphi. Fondamentalement, je veux avoir des comptes d'utilisateurs où l'utilisateur appartient à un seul groupe. Un groupe peut avoir "n" nombre de droits.

Je souhaite également ajouter l'historique des mots de passe à la base de données, car l'utilisateur devra modifier son mot de passe en fonction d'un paramètre d'application (par exemple, tous les 90 jours).

Je souhaite également enregistrer un événement à chaque fois qu'un utilisateur se connecte et se déconnecte. Je peux étendre cela à d'autres événements à l'avenir.

Ci-dessous, vous y trouverez ma première fissure. Veuillez me faire part de vos suggestions pour l'améliorer, car c'est la première fois que je fais cela.

Voyez-vous le besoin d'attributs supplémentaires pour la sécurité basée sur les rôles et les contraintes pour les règles de mot de passe/périodes d'expiration?

db-design

database-designdatatypesrelational-theorydatabase-tuning
15
Johnny Holmes

En fonction de vos exigences, votre modèle est en assez bon état.

Voici quelques suggestions d'amélioration:

  • Vous ne le dites pas explicitement, il est donc difficile de le dire - mais il semble que vous stockiez directement le mot de passe de l'utilisateur. Ce serait très mauvais! Si vous regardez les bases de données d'authentification courantes, les mots de passe sont stockés sous forme cryptée. Vous voyez souvent à la fois une colonne password et un password_salt colonne.

  • Votre USER_LOGS table a une colonne Event. Vous ne savez pas comment cela doit être rempli. Devrait-il y avoir un EVENT_TYPE table qui USER_LOGS références? Cela pourrait rendre les rapports plus conviviaux. Les événements typiques incluent la connexion, la déconnexion, l'échec du mot de passe, le changement de mot de passe, la réinitialisation du mot de passe, le verrouillage, le déverrouillage, ...

  • Votre GROUP_RIGHTS le tableau n'indique pas qui a accordé les droits. À des fins de piste d'audit, les gens gardent souvent un journal de qui a changé quoi et quand. Ce n'est peut-être pas un problème pour vous.

Voici quelques questions concernant vos exigences commerciales déclarées, qui diffèrent du modèle de sécurité basé sur les rôles de "manuel" de deux manières:

  • Voulez-vous vraiment que les utilisateurs appartiennent à un seul groupe? L'avantage de la sécurité basée sur les rôles est que les rôles ont tendance à être assez statiques, tandis que les personnes remplissant les rôles vont et viennent assez souvent. Cela inclut que certaines personnes "portent souvent deux chapeaux".

  • Votre conception est uniquement subventionnée. Certains systèmes incluent accorder et révoquer. Cela vous permet de dire qu'un droit largement disponible n'est pas disponible pour un groupe particulier.

  • Vous avez des utilisateurs et des comptes associés à USERS dans votre conception. Il existe souvent une distinction entre personnes et ID utilisateur . Certains ID utilisateur sont destinés à des équipes ou des machines et certaines personnes ont plusieurs ID utilisateur à des fins différentes. Est-ce une distinction qui vous serait utile?

11
Joel Brown

Je pense que les opérateurs au niveau du bit sont le meilleur moyen de mettre en œuvre l'autorisation utilisateur. Ici, je montre comment nous pouvons l'implémenter avec Mysql.

Voici un exemple de tableaux avec quelques exemples de données:

Tableau 1 : table des autorisations pour stocker le nom de l'autorisation avec son bit comme 1,2,4,8..etc (multiple 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;

Insérez quelques exemples de données dans le tableau.

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

Tableau 2 : Tableau utilisateur pour stocker l'ID utilisateur, le nom et le rôle. Le rôle sera calculé comme la somme des autorisations.
Exemple :
Si l'utilisateur 'Ketan' a la permission de 'User-Add' (bit = 1) et 'Blog-Delete' (bit-64), le rôle sera donc 65 (1 + 64).
Si l'utilisateur "Mehata" a l'autorisation de "Blog-View" (bit = 128) et "User-Delete" (bit-4), le rôle sera donc 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;

Exemples de données-

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

Autorisation de dépôt de l'utilisateur Après la connexion si nous voulons charger l'autorisation de l'utilisateur, nous pouvons interroger ci-dessous pour obtenir les autorisations:

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

Ici user.role "&" permission.bit est un opérateur Bitwise qui donnera la sortie comme -

User-Add - 1
Blog-Delete - 64

Si nous voulons vérifier la météo, un utilisateur particulier a la permission de modifier ou non

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

Sortie = Aucune ligne.

Vous pouvez également voir: http://goo.gl/ATnj6j

3
Suresh Kamrushi