ASP.NET MVC Autorisation et rôles par team_id

Question

Je commence un projet en utilisant ASP.NET MVC et je n'arrive pas à comprendre quelle est la meilleure façon de gérer les autorisations et les rôles en fonction d'un id_collectif. Chaque entrée de blog ou forum que je lis parle toujours de la définition d'un rôle global ("admin", "helpdesk", "editor", etc ...) utilisant l'appartenance asp.net ou créant un filtre CustomAuthorize. Le problème dans mon application est qu'il n'y a pas de rôles globaux. Un utilisateur va être gestionnaire de team1, mais ne peut pas modifier ou afficher les détails de team2. Les détails d'autorisation sont: - Un utilisateur peut voir sa planification d'équipe et la disponibilité de ses coéquipiers, mais ne peut pas voir d'autres équipes - le chef d'équipe peut modifier les détails de l'équipe, mais ne peut pas modifier les détails d'une autre équipe - Une équipe peut avoir 1 ou de nombreux gestionnaires - Un utilisateur peut faire partie de 1 ou plusieurs équipes

ATM, j'ai 3 tables pour gérer cette relation.

teams --> teams_users <-- users 
team_id #team_id  user_id 
      #user_id 
      isManager? 

En dernier recours, je suis planing sur le stockage actuel team_id et de l'état isManager de l'utilisateur en session vars quand il se connecte, et de créer un filtre CustomAuthorize qui vérifiera si la session team_id est le même que model.team_id. Faites-moi savoir s'il y a une autre façon de le faire. Merci

Answer 1

Enfin, je fini par créer un itinéraire personnalisé:

/{team_id}/controller/action/{id} 

{team_id} est définie une fois l'utilisateur se connecte dans, puis un filtre personnalisé vérifie que l'utilisateur appartient à l'équipe au-dessus de chaque contrôleur. Chaque fois qu'il change d'équipe, le {team_id} est mis à jour. En outre, il existe un filtre "isManager" pour sécuriser une action de gestionnaire spécifique qui vérifiera si l'utilisateur est le manager de l'équipe actuelle. Merci les gars pour vos réponses

Answer 2

Je aurais alors 2 rôles - Gestionnaire et utilisateur Ensuite, je lierais dans la base de données comme vous l'avez spécifié. Les rôles contrôleraient les actions que chaque utilisateur peut effectuer (l'utilisateur peut afficher des informations, un gestionnaire peut modifier/créer des informations), puis dans chaque action je ferais un contrôle rapide de l'utilisateur actuel. Effectuez cette action sur l'équipe qui serait requise (c'est-à-dire que l'utilisateur a accès à l'équipe).

Answer 3

J'ai développé deux attributs personnalisés pour gérer les cas suivants: RoleOrOwnerAuthorization et RoleOrOwnerAssociatedAuthorization. RoleOrOwner cherche à voir si l'utilisateur actuel du système est le même que l'ID utilisateur des données en question. Autrement dit, vous êtes autorisé à afficher vos propres données. RoleOrOwnerAssociated vérifie s'il existe une ligne dans une table de jointure reliant les données à l'utilisateur actuel. Par exemple, je peux avoir des groupes, des GroupLeaders et des utilisateurs, où GroupLeaders est une table de jointure reliant des groupes aux utilisateurs. Pour afficher les données d'un groupe, vous devez être dans le rôle ViewGroups ou être un chef de groupe (comme en témoigne une ligne dans GroupLeaders avec l'ID du groupe et votre ID). Je pense que cela fonctionne très bien.

Answer 4

Je pense que votre solution semble bonne. Si vous comptez beaucoup sur les rôles ASP.NET pour faire la levée initiale pour vous, vous aurez beaucoup de problèmes:

L'utilisateur 1 est un gestionnaire pour l'équipe 1 et un utilisateur régulier pour l'équipe 2. ViewSchedule est en lecture seule pour utilisateurs et modifiable pour les gestionnaires. Code sur ViewSchedule:

if (User.IsInRole("manager")) { 
    if (isTeamManager(userid)) {} 
} 
else {} 

bool isTeamManager(int userid) { 
    return db.IsTeamManager(userid) { 
} 

Si vous faites cela, alors quand l'utilisateur utilise équipe 2, il va manquer ce bloc tout à fait. Il est un gestionnaire en ce qui concerne les rôles ASP.NET mais n'est pas un pour cette équipe.Pas de problème, il est évident que nous pouvons combiner les conditionals comme ceci:

if (User.IsInRole("manager") && isTeamManager(userid)) { } 
else {} 

Ah oui, et si nous appelons isTeamManager() alors nous sommes déjà obtenir la seule information qui User.IsInRole (le « gestionnaire ») fournit donc nous n'en avons même pas besoin:

if (isTeamManager(userid)) { } 
else {} 

Alors maintenant, nous n'utilisons même pas de rôles dans notre code. Je voudrais juste rester avec votre idée originale.