10
votes

Motifs / Suggestions de conception pour la manipulation de permission

Nous avons un système de traitement d'autorisation plutôt compliqué dans notre application (ASP.NET Web). Les utilisateurs peuvent avoir des autorisations spécifiques sur différents types d'objets, certaines autorisations sont même emballées dans des groupes / rôles attribués aux utilisateurs. Tout cela finit dans un désordre assez compliqué où pour déterminer si un utilisateur peut faire / voir quelque chose que vous devez évaluer de nombreuses sources d'autorisations différentes et cela se fait en quelque sorte à la demande et en fonction de situations spécifiques.

Ma question est (à partir d'un point de vue de haut niveau) s'il existe des suggestions de suggestions / des modèles de conception courants pour traiter le concept de permission en général et probablement aussi quelle est votre expérience de les manipuler dans votre architecture.


2 commentaires

Il existe également une "adhésion asp.net" en 3.5 qui dispose de certaines installations pour traiter cela, mais je ne sais pas comment les programmeurs sont conviviaux.


Une bonne question, qui nécessite une meilleure réponse que celles énumérées ci-dessous. Je regarde quelque chose de similaire en Java, mais permettant aux autorisations héritées. J'ai eu du mal à trouver des modèles / des algorithmes sur le net.


3 Réponses :


6
votes

utilisateurs et Groupes avec la possibilité de tester BOOL userhaspermission (quelque_permission) pour une autorisation atomique associée à un groupe est l'approche standard pour Autorisation, cependant, les choses changent de revendications:

http://msdn.microsoft.com/en-us/magazine/ EE335707.aspx

http://msdn.microsoft.com/en-us/magazine/ CC163366.aspx

http://www.infoq.com/news/ 2009/10 / Guide-Réclamation - Identity

Cependant, n'est pas idéal pour toutes les situations.

Pour l'ancien modèle, je trouve que les performances peuvent être gagnées à l'aide de la mémoisation lors des contrôles d'autorisations. De cette façon, je ne vais pas à la base de données N Times par session pour vérifier le contrôle d'accès. La mémoisation stocke efficacement dans un cache le résultat d'un appel avec les mêmes paramètres, de sorte que tous les appels par un utilisateur particulier pour vérifier la permission XYZ renvoient le même résultat. Bien sûr, vous vous assurez que vous avez stocké les autorisations mémorisées pour l'utilisateur de la session afin qu'il soit par utilisateur. Si vous chargez les autorisations à la connexion, vous n'avez pas besoin de les mettre en cache, mais dans de grands systèmes avec de nombreuses autorisations, il est préférable de les obtenir que lorsque cela n'est nécessaire.

0 commentaires


2
votes

Je n'ai pas traité cela à partir d'un point de vue du développement des applications, mais souvent lors de la gestion des autorisations, il est une bonne pratique pour définir des autorisations pour des objets à l'aide de rôles, plutôt que de donner à l'autorisation des utilisateurs directement à l'objet. Si un utilisateur a besoin d'accéder à un ensemble particulier d'objets, vous ne leur donnez pas accès directement, vous leur donnez plutôt un rôle, ce qui a à son tour l'accès nécessaire. Cela "réutilise" le travail qui a été mis en création du rôle.

traiter avec cela dans le code, cependant peut être compliqué, car vous devez itérayer à travers chacun des rôles d'un utilisateur et déterminer si le rôle confère à l'utilisateur l'objet. Je ne connais aucune suggestion spécifique sur la gestion de cette autre chose que l'évidence d'essayer de prendre en compte ce type de code dans son propre cadre.


1 commentaires

Peut-être qu'il n'y a pas de meilleur moyen, c'est fondamentalement la question;) Nous avons en fait des concepts de ces groupes et de rôles qui le rendent très pratique pour l'utilisateur final qui a diverses manières de configuration des autorisations. Le problème est plus un problème de maintenance pour nous où gérer toutes ces sources différentes devient de plus en plus fastidieuse.



8
votes

J'ai vu plusieurs systèmes de permission compliqués. Il y avait toujours une justification pour cela, mais malheureusement, à un moment donné, ils sont tous devenus trop compliqués pour traiter et ont été réduits à quelque chose de plus simple.

Ma conclusion personnelle est maintenant: Stick to Contrôle d'accès à la base de rôle ( RBAC ) C'est le seul raisonnable que tout le monde comprend. C'est en quelque sorte limité, mais suffisant pour la plupart des cas.

Aussi, utilisez NYY par défaut , c'est-à-dire que vous accordez uniquement des droits. Encore une fois, j'ai vu le système avec le contraire (autoriser par défaut) ou même une stratégie par défaut configurable (!) Et je ne pense pas que cela soit raisonnable.


0 commentaires