Extension des fournisseurs de rôle ASP.NET

Question

Étant donné que l'interface RoleProvider ne semble traiter les rôles que comme de simples chaînes, je me demande s'il existe une façon non hacker d'appliquer une valeur facultative pour un rôle pour chaque utilisateur. . Notre système de gestion des connexions actuel implémente des rôles en tant que paires clé-valeur, où la partie valeur est facultative et généralement utilisée pour clarifier ou limiter les autorisations accordées par un rôle. Par exemple, un rôle 'éditeur' peut contenir un utilisateur 'barry', mais pour 'barry' il aura une valeur optionnelle 'raptors', que le système interpréterait comme signifiant que Barry ne peut éditer que les articles déposés sous la catégorie des «rapaces».

J'ai vu ailleurs une suggestion de créer simplement des rôles délimités supplémentaires, tels que 'editor.raptors' ou quelque chose comme ça. Cela ne va pas vraiment être idéal parce que cela gonflerait énormément le nombre de rôles, et je peux dire que ça va être très difficile à vendre pour remplacer notre implémentation actuelle (qui est aussi très loin d'être idéale, mais qui a l'avantage d'être personnalisée fait pour travailler avec notre base de données utilisateur).

Je peux déjà dire que la méthode de concaténation mentionnée ci-dessus va impliquer beaucoup de fastidieux dédoublement de chaînes et d'appariement partiel.

Y a-t-il un meilleur moyen?

EDIT: Mon objectif initial était d'utiliser davantage de fonctionnalités ASP.NET intégrées. Par exemple, contrôlez l'accès via les éléments <authorization/> dans Web.config. Pour autant que je puisse le voir, cela nécessite de mettre en place des rôles eux-mêmes. Le concept d'auths de notre système actuel semblait très bien aller au-delà de cette limitation.

des questions de réponse à mnemosyn

1. Oui. Nous disposons d'une base de données centrale pour les utilisateurs, les applications et leurs autorisations. C'est un système de base et il n'y a pas de problème.
2. Actuellement, notre système n'est pas hiérarchique, et cela demande beaucoup d'efforts. Lorsqu'une application est créée, un ensemble d'autorisations est défini (par exemple, 'admin', 'user', 'poweruser', 'gatekeeper', 'keymaster', etc.). Les utilisateurs sont ensuite associés à ces autorisations avec la valeur facultative pour une combinaison unique d'utilisateur et d'autorisation (spécifique à l'application).
3. Pouvez-vous élaborer sur ces «catégories» dont vous parlez?

Answer 1

Cela ressemble vraiment à un problème d'architecture pour moi.

D'abord, vous devez déterminer exactement ce dont vous avez besoin. Dans un deuxième temps, mappez ceci à une implémentation concrète. Pour aller de l'avant sur celui-là: je n'utiliserais pas les fournisseurs intégrés pour autre chose que les cas les plus simplistes. En outre, ce problème devient rapidement très compliqué, alors je vais essayer de le garder aussi simple que possible.

Pour élaborer vos besoins, essayez de déterminer:

• Avez-vous vraiment besoin de cartographier le concept de rôle à la base de données, comme vous le feriez dans un CMS? Ou les modifications apportées à votre système de rôle impliquent-elles une modification du système? Dans ce cas, vous pouvez opter pour une solution beaucoup plus simple et mettre une énumération dans l'utilisateur. Cela permettra d'économiser beaucoup d'accès à la base de données, rend les jointures simples, etc.
• Qu'essayez-vous d'accomplir grâce au concept multi-rôles que vous avez expliqué? Est-ce vraiment les rôles dont vous avez besoin? Que diriez-vous des permissions individuelles? Avez-vous, par exemple, une structure hiérarchique pour que chaque nœud puisse avoir un certain ensemble d'autorisations, tout comme le concept de sécurité des fichiers de Windows?
• S'il s'agit uniquement de catégories, pourquoi ne pas mapper les catégories aux utilisateurs, c'est-à-dire attribuer à chaque utilisateur un rôle spécifique dans chaque catégorie. Cela nécessitera quelques réglages pour la catégorie par défaut, etc.

Voici quelques conseils: N'utilisez pas les listes blanches, utilisez toujours des listes noires. Contrôler les listes blanches est une douleur, en particulier quand beaucoup de règles se réunissent. Dans drupal, par exemple, je pense que c'est l'un des défauts majeurs (c'est pourquoi ils le reconstruisent pour utiliser des listes noires dans la version 7). Permettre à un utilisateur de faire quelque chose qu'il ne devrait pas faire est généralement un problème beaucoup plus important que l'inverse. Le concept d'accès aux fichiers Windows est très compliqué, car il contient à la fois des listes noire et blanche, qui peuvent en outre être héritées. Essayez donc de garder votre solution beaucoup plus simple que cela. La chaîne de concaténation thingie semble plutôt dangereuse pour moi, j'irais pour une solution plus propre dans tous les cas. Ce type de méta-logique donne mal à la tête.