Quelle est la meilleure façon de gérer plusieurs types d’autorisations ?

Question

Je rencontre souvent le scénario suivant dans lequel je dois proposer de nombreux types d'autorisations différents.J'utilise principalement ASP.NET/VB.NET avec SQL Server 2000.

Scénario

Je souhaite proposer un système d'autorisation dynamique qui peut fonctionner sur différents paramètres.Disons que je souhaite donner à un service ou simplement à une personne spécifique l'accès à une application.Et prétendons que nous disposons d’un certain nombre d’applications qui ne cessent de croître.

Dans le passé, j'ai choisi l'une des deux méthodes suivantes que je connais pour procéder.

1. Utilisez une seule table d'autorisation avec des colonnes spéciales utilisées pour déterminer une façon d'appliquer les paramètres.Les colonnes spéciales de cet exemple sont TypeID et TypeAuxId.Le SQL ressemblerait à ça.

   SELECT COUNT(PermissionID)
   FROM application_permissions
   WHERE
   (TypeID = 1 AND TypeAuxID = @UserID) OR
   (TypeID = 2 AND TypeAuxID = @DepartmentID)
   AND ApplicationID = 1
   

2. Utilisez une table de mappage pour chaque type d'autorisation, puis vous joignez tous ensemble.

   SELECT COUNT(perm.PermissionID)
   FROM application_permissions perm
   LEFT JOIN application_UserPermissions emp
   ON perm.ApplicationID = emp.ApplicationID
   LEFT JOIN application_DepartmentPermissions dept
   ON perm.ApplicationID = dept.ApplicationID
   WHERE q.SectionID=@SectionID
     AND (emp.UserID=@UserID OR dept.DeptID=@DeptID OR
    (emp.UserID IS NULL AND dept.DeptID IS NULL)) AND ApplicationID = 1
   ORDER BY q.QID ASC
   

Mes pensées

J'espère que les exemples ont du sens.Je les ai bricolés.

Le premier exemple nécessite moins de travail, mais aucun des deux ne semble être la meilleure réponse.Existe-t-il une meilleure façon de gérer cela ?

Answer 1

Je suis d'accord avec John Downey.

Personnellement, j'utilise parfois une énumération d'autorisations marquée.De cette façon, vous pouvez utiliser les opérations au niveau du bit AND, OR, NOT et XOR sur les éléments de l'énumération.

"[Flags]
public enum Permission
{
    VIEWUSERS = 1, // 2^0 // 0000 0001
    EDITUSERS = 2, // 2^1 // 0000 0010
    VIEWPRODUCTS = 4, // 2^2 // 0000 0100
    EDITPRODUCTS = 8, // 2^3 // 0000 1000
    VIEWCLIENTS = 16, // 2^4 // 0001 0000
    EDITCLIENTS = 32, // 2^5 // 0010 0000
    DELETECLIENTS = 64, // 2^6 // 0100 0000
}"

Ensuite, vous pouvez combiner plusieurs autorisations à l’aide de l’opérateur bit à bit AND.

Par exemple, si un utilisateur peut afficher et modifier des utilisateurs, le résultat binaire de l'opération est 0000 0011, qui converti en décimal est 3.
Vous pouvez ensuite stocker l'autorisation d'un utilisateur dans une seule colonne de votre base de données (dans notre cas, ce serait 3).

Dans votre application, vous avez juste besoin d'une autre opération au niveau du bit (OU) pour vérifier si un utilisateur dispose ou non d'une autorisation particulière.

Answer 2

La façon dont je procède généralement pour coder les systèmes d’autorisation consiste à avoir 6 tables.

• Utilisateurs - c'est assez simple, c'est votre tableau d'utilisateurs typique
• Groupes - ce serait synonyme de vos départements
• Rôles - il s'agit d'un tableau avec toutes les autorisations, comprenant généralement également un nom lisible par l'homme et une description
• Users_have_Groups - il s'agit d'un tableau plusieurs-à-plusieurs des groupes auxquels un utilisateur appartient
• Users_have_Roles - un autre tableau plusieurs-à-plusieurs des rôles attribués à un utilisateur individuel
• Groups_have_Roles - le tableau final plusieurs-à-plusieurs des rôles de chaque groupe

Au début d'une session utilisateur, vous exécuterez une logique qui extraira tous les rôles qui leur ont été attribués, soit dans un annuaire, soit via un groupe.Ensuite, vous codez en fonction de ces rôles en tant qu'autorisations de sécurité.

Comme je l'ai dit, c'est ce que je fais habituellement, mais votre millage peut varier.

Answer 3

En plus des solutions de John Downey et de jdecuyper, j'ai également ajouté un bit "Explicit Deny" à la fin/au début du champ de bits, afin que vous puissiez effectuer des autorisations additives par groupe, appartenance à un rôle, puis soustraire des autorisations basées sur un refus explicite. entrées, un peu comme NTFS fonctionne, en termes d'autorisation.

Answer 4

Honnêtement, les fonctionnalités d'adhésion/rôles ASP.NET fonctionneraient parfaitement pour le scénario que vous avez décrit.Écrire vos propres tables/procs/classes est un excellent exercice et vous pouvez obtenir un très bon contrôle sur les moindres détails, mais après l'avoir fait moi-même, j'ai conclu qu'il était préférable d'utiliser simplement les éléments .NET intégrés.Une grande partie du code existant est conçu pour contourner ce problème, ce qui est bien.Écrire à partir de zéro m'a pris environ 2 semaines et ce n'était pas aussi robuste que les .NET.Vous devez coder tellement de conneries (récupération de mot de passe, verrouillage automatique, cryptage, rôles, interface d'autorisation, des tonnes de procédures, etc.) et le temps pourrait être mieux dépensé ailleurs.

Désolé si je n'ai pas répondu à votre question, je suis comme le gars qui dit d'apprendre le c# quand quelqu'un pose une question en vb.

Answer 5

Une approche que j'ai utilisée dans diverses applications consiste à disposer d'une classe PermissionToken générique dotée d'une propriété Value modifiable.Ensuite, vous interrogez l'application demandée, elle vous indique quels PermissionTokens sont nécessaires pour l'utiliser.

Par exemple, l'application Expédition peut vous indiquer qu'elle a besoin :

new PermissionToken()
{
    Target = PermissionTokenTarget.Application,
    Action = PermissionTokenAction.View,
    Value = "ShippingApp"
};

Cela peut évidemment être étendu à Créer, Modifier, Supprimer, etc. et, grâce à la propriété Value personnalisée, n'importe quelle application, module ou widget peut définir ses propres autorisations requises.YMMV, mais cela a toujours été une méthode efficace pour moi que j'ai trouvée bien adaptée.