Critique mon schéma de système d'authentification DB?

Question

Je suis en train de concevoir une application Web RESTful qui fournira un système d'authentification pour plusieurs autres applications. Les autres applications interrogeront cette application via HTTP et récupèreront le XML décrivant les utilisateurs authentifiés.

L'application d'authentification doit garder une trace des que les utilisateurs sont autorisés à faire ce que sur les applications.

Je travaille sur le schéma DB. Voici ma conception initiale. (Supposons que chaque table a une colonne id.)

applications # The various client apps that will query this auth system. 
------------ 
name 

users   # Table simplified for discussion 
----- 
username 
password 
email 

roles 
----- 
name 
application_id 

roles_users 
----------- 
role_id 
user_id 

L'idée est de dire que quelqu'un a essayé d'exécuter une fonction administrative dans l'application du « Matériel d'inventaire ». Donc, "Inventaire de l'équipement" dirait au système d'authentification "obtenir l'utilisateur avec le nom d'utilisateur xxx et le mot de passe yyy." Ensuite, il regarde l'objet retourné (via ActiveResource) User et vérifie si son roles Array contient un Role avec un nom de "ADMIN" qui lui-même appartient à un objet Application avec un nom de "Inventaire d'équipement".

Ou peut-être il serait préférable d'éliminer la table applications et ont beaucoup plus de rôles, par exemple, « equipment_inventory_admin », « equipment_inventory_readonly », « job_tracker_admin », etc.

Ce qui est plus important, normalisant l'entité d'application ou simplifier la structure de la table? Peut-être après tout ce tapage je viens de répondre à ma propre question, mais les commentaires ou les suggestions seraient les bienvenus.

Answer 1

Le schéma semble sain d'esprit, Vous enverriez

<login><username>abc</username><password>xyz</password><app>51</app></login>

et vous retourner

<auth> <user> <username>abc</a> <lastlogin>123456464</lastlogin> </user> <app> <name>Equipment Inventory</name> <version>3.1.5e</version> </app> <roles> <role>admin</role> <role>manager</role> <role>dataentry</role> </roles> </auth>

ou

<auth><error type="1"></auth>

Answer 2

Personnellement j'ai tendance à pécher du côté de la normalisation. Au moins, d'après mon expérience, des modules supplémentaires sont ajoutés. Beaucoup plus facile d'ajouter une ligne supplémentaire dans l'application et de nouvelles tables si nécessaire, puis de modifier le schéma existant et d'avoir à mettre à jour tous les codes d'accès aux données pertinents. Edit: Sur un second regard, vous pouvez fusionner la table des rôles et la table roles_users. Il peut s'agir d'un endroit qui définit les rôles et de la façon dont les utilisateurs peuvent y accéder pour chaque application.

Answer 3

Authentification définitivement séparée de l'autorisation. (On dirait que vous faites cela, la table "utilisateur" tombe dans l'authentification, le reste + user.id tomber dans l'autorisation)

Mots de passe: vous ne les stockez pas en clair, êtes-vous? Le stockage des hachages MD5 (+ salt pour empêcher les attaques) serait plus sûr.

Est-ce que Kerberos serait une possibilité? (peut-être pourrait-il être adapté pour fonctionner sur HTTP en tant que couche de transport)