Comment affecter des rôles d'appartenance .net à des enregistrements de base de données individuels

Question

Je développe un système dans lequel nous souhaitons limiter la disponibilité des informations affichées aux utilisateurs en fonction de leurs rôles.

par exemple. J'ai appelé EventType (ID, EventTypeDescription) déposé qui contient les documents suivants:

1, 'Basic Event' 
2, 'Intermediate Event' 
3, 'Admin Event' 

Ce que je dois obtenir est de filtrer les enregistrements renvoyés en fonction du nom d'utilisateur (et donc le rôle) de l'utilisateur connecté. Par exemple, si un utilisateur avancé est connecté, il verra tous les types d'événements, si l'utilisateur standard est connecté, il ne verra que le type d'événement de base, etc.

Idéalement, je voudrais faire cela d'une manière qui peut être facilement étendu à d'autres tables si nécessaire. Donc, je voudrais éviter d'ajouter simplement un champ "Rôles" à chaque table où les données sont sensibles au contexte de l'utilisateur.

Une idée je pense est de créer une sorte de permissions table comme:

PermissionsTable 
(
    ID, 
    Aspnet_RoleId, 
    TableName, 
    PrimaryKeyValue 
) 

ce qui a l'inconvénient d'utiliser ce système est évidemment d'avoir à utiliser le nom de la table pour changer la table à se joindre sur .

Edit: En l'absence de meilleures suggestions, je vais aller avec la dernière idée je l'ai mentionné, mais au lieu d'avoir un champ TableName, je vais normaliser la TableName vers son propre table comme suit:

TableNames 
(
    ID, 
    TableName 
) 

UserPermissionsTable 
(
    ID, 
    Aspnet_UserId, 
    TableID, 
    PrimaryKeyValue 
) 

Answer 1

Nous faisons quelque chose de similaire, Notre solution consistait à utiliser une fonction de valeur table à joindre. ie.

select * des événements e INNER JOIN [dbo] .fn_AvailableEvents (@User_ID) sur un e.id = a.id

la fonction retourne uniquement l'ID d'événement des événements que l'utilisateur est autorisé à voir .

Answer 2

vous ne mentionnez pas ce que (le cas échéant) base de données que vous utilisez, mais en supposant SQL Server puis si vous vous connectez avec l'authentification Windows, vous pouvez créer des vues ou des procédures stockées qui filtraient les données sur la base sur la fonction SYSTEM_USER.

Answer 3

Même si vous ne l'utilisez pas, c'est dommage, vous pouvez au moins apprendre les tenants et les aboutissants du concept de Rhino.Security.

Answer 4

j'ai fait quelque chose de similaire tout en construisant un CMS ...

Essentiellement j'ai créé quelques tables dans la db: Utilisateurs Rôles UsersInRoles Objets ObjectPermissions

Ok cela fonctionne quelque chose comme ça. ..

Les 3 premiers sont assez explicites, les utilisateurs, les rôles et les liens entre eux. Un utilisateur reçoit des autorisations en fonction de son appartenance aux rôles. La prochaine chose que je fais est de définir les "objets" dont je veux contrôler les permissions et les niveaux d'autorisation que je veux leur assigner ...Par conséquent, les objets contiennent une liste des définitions d'objets qui sont ensuite étendues dans d'autres tables liées par l'ID d'objet et la table ObjectPermissions lie fondamentalement un objet à un rôle.

Maintenant, à ce stade, il pourrait y avoir quelque chose de la peine d'expliquer au sujet des rôles ...

Un rôle que je vois une liste des autorisations, rien de plus et rien de moins.

Donc, si je crée un rôle appelé invité et définissez le rôle pour permettre l'autorisation de lecture puis créez un rôle d'administrateur appelé qui a des droits mondiaux pour faire tout ce que je peux faire quelque chose comme ça ...

Ajouter un utilisateur 1 Rôle d'administrateur. Ajouter l'objet 1 au rôle d'administrateur. L'utilisateur 1 aurait maintenant un accès complet à l'objet 1 et l'important ici est que les autorisations soient héritées afin que tous les objets enfants (pensez aux autorisations de fichiers et de dossiers) soient également dans le même jeu de rôles sauf s'ils sont remplacés récursivement. Par conséquent, j'attribue par défaut l'objet de niveau racine à chaque rôle système clé. Ensuite, j'ajoute sélectivement des utilisateurs à différents rôles à différents endroits de l'arbre.

Est-ce que cela a du sens? Essentiellement, je peux choisir n'importe quel objet et n'importe quel utilisateur et accorder un degré variable d'autorisations à l'utilisateur sur cet objet et ses enfants en ajoutant l'utilisateur au même rôle que l'objet.

Maintenant, il y a des choses à noter à ce sujet ....

Si je voulais un utilisateur de disposer des droits d'administrateur sur un objet profondément imbriqué, mais pas au niveau de la racine je dois créer un nouveau rôle qui accorde tous autorisations et ajouter à la fois l'utilisateur et l'objet.

La raison étant que si j'ajoutais l'utilisateur au rôle d'administrateur principal, l'utilisateur recevrait ces droits du niveau racine et non de mon objet imbriqué.

il y a plus que cela, mais c'est essentiellement ainsi que fonctionnent les permissions du système de fichiers.