AzMan Nested Roles ne trouve pas l'utilisateur dans le rôle

Question

J'utilise AzMan (1.0) pour une application web ASP.Net, et j'ai une question sur les rôles imbriqués.

Dire que j'ai les rôles suivants: MyApp MyAppUser MyAppAdmin MyAppSupport

Pour la plupart, tous les utilisateurs (MyApp) peuvent accéder à l'application, mais certaines fonctions sont spécifiques aux autres rôles.

Je souhaite limiter de manière déclarative l'accès aux pages Web aux membres du rôle MyApp.

[PrincipalPermission(SecurityAction.Demand, Role = "MyApp")] 

Je vais vérifier User.IsInRole ou utiliser l'API AzMan pour vérifier les autorisations de fonctionnement dans mon code.

Les utilisateurs sont affectés aux rôles de niveau inférieur (utilisateur, administrateur, support) et ces rôles sont ajoutés au rôle MyApp.

Le problème est que lorsque je vérifie si l'utilisateur est membre du rôle MyApp, ce n'est pas le cas, même si le rôle dans lequel il se trouve appartient au rôle MyApp. Est-ce que le seul moyen de vérifier cela est de parcourir récursivement tous les rôles? Cela signifierait que je ne peux pas utiliser la sécurité déclarative, ou pour ce faire, je devrais également ajouter tous les utilisateurs au groupe de niveau supérieur (pas idéal).

Answer 1

Il semble que vous attendiez une définition de rôle composite (où une définition de rôle est définie pour inclure d'autres définitions de rôle) à prendre en charge dans l'appel à IsInRole(). Je pense que vous obtiendriez les résultats souhaités si vous utilisiez l'héritage de groupe et l'attribution de rôle à la place. En d'autres termes, plutôt que de dépendre de IsInRole pour suivre la définition de rôle pour "MyApp" afin de déterminer que la définition de rôle "MyAppAdmin" fait partie de cette définition, créez l'héritage à l'aide de Groups, puis affectez-en un ou plusieurs. groupes à votre définition de rôle à l'aide de l'attribution de rôle. Vous pouvez créer un groupe "Administrateurs", qui peut être membre du groupe "Tout le monde". Je pense vraiment que vos noms de rôle sont de meilleurs noms de groupe. Un rôle signifie certaines capacités, pas une classification des utilisateurs en fonction de leurs droits. C'est à ça que sert un groupe. Par exemple, supposons que la plupart des utilisateurs (pas les administrateurs ou le support) ont un accès en lecture seule à votre application. J'ai tendance à appeler ce rôle "Viewer" et je lui assigne les tâches ou les opérations qui permettent aux utilisateurs de ce rôle seulement la possibilité de voir, et non d'éditer, des données. J'attribuerais tout le monde à ce rôle (que je le fasse avec un seul ou plusieurs groupes n'a pas vraiment d'importance). Le rôle "Support" permet aux utilisateurs qui lui sont affectés d'effectuer certaines opérations (ou opérations de regroupement de tâches). Seules certaines personnes seraient affectées à ce rôle (encore une fois, elles sont peut-être assignées individuellement, ou j'ai un groupe nommé "Customer Support Reps" - peu importe).

Dans mon application, je pourrais vérifier IsInRole("Viewer") et tout le monde qui est un utilisateur sera dans ce rôle. Mais si je coche IsInRole("Support"), seules les personnes du groupe "Customer Support Reps" affectées à ce rôle retourneront True.