Définition d'un modèle de sécurité avec des autorisations/rôles implicites

Question

Je travaille sur un système de rôles/permissions pour mon application web et je ne sais pas trop comment structurer cela.

En résumé. Les utilisateurs peuvent accéder à un certain nombre de projets. Ceci est une participation et, entre autres choses, une participation a un profil avec un certain nombre de droits. Ce sont donc des droits spécifiques à un utilisateur dans un projet. Une Participation a aussi un Type (Admin, Support, etc.).

Un profil est basé sur un rôle. Les rôles (peut-être mal nommés) sont effectivement des profils standard avec des configurations de droits par défaut définies à l'avance par les administrateurs. Lors de la création d'un nouveau profil, on choisit un rôle pour agir comme base et ensuite, si nécessaire, on ajuste les droits. Les profils ne sont pas exclusifs à un utilisateur.

Jusqu'à présent, si bien (ou pas! Vous me dire!)

Les droits sont regroupés par contexte/sujet. Ainsi, par exemple, tous les droits relatifs aux «tâches de projet» sont regroupés. Je n'ai pas modélisé cela parce que c'est géré par l'interface utilisateur (je ne sais pas si c'est une mauvaise chose).

Maintenant, mon problème est le suivant. Selon le type de participation, certains droits sont implicites et ne doivent pas être désactivés. Ainsi, lors de la création d'un rôle pour une participation «Support», le droit «Voir mes propres tickets de support» doit être implicite et non affiché, ou désactivé pour ne pas pouvoir être modifié. Alors qu'un type de participation différent peut éventuellement affecter ce droit ou non.

J'ai essentiellement une feuille de calcul avec le type de participant/droit = ​​ne peut pas appliquer, peut s'appliquer (sélectionné ou non) & Toujours s'applique. par exemple:

| RIGHT    | INV | SUP | ADM | 
| ------------------ | --- | --- | --- | 
| G_PROJECTS_READ | I | I | Y | 
| G_PROJECTS_UPDATE | Y | N | Y | 
| G_PROJECTS_CREATE | N | N | Y | 
| G_PROJECTS_PUBLISH | N | N | Y | 

Where Y = Type can toggle right on/off, N = Type doesn't have right 
& I = Implied i.e. Type has right and it can't be deselected 

Des idées/des pointeurs sur la façon dont cela peut être modélisé?

Un grand merci,

AW

Answer 1

Les rôles sont essentiellement des profils prédéfinis. En tant que tels, les différents rôles ne seront que des exemples de profils créés lors de l'initialisation de l'application. Nous n'aurons pas besoin de rôle en tant que classe/entité distincte.

Créer un interface IProfile qui a les méthodes Set<Right> getAllRights(), Set<Right> getEditableRights() et Set<Right> getAllowedRights(). La méthode getAllowedRights() donne les droits par défaut que tout utilisateur appartenant à ce profil a (Ces droits ne peuvent pas être modifiés). La méthode getEditableRights() montre quels droits peuvent être modifiés par un administrateur lors de la création d'un nouveau rôle.

Maintenant arrivant à Profile, il est composé de Type et implémente IProfile. Maintenant, vous pouvez mettre en œuvre le profil comme

public class Profile implements IProfile { 
    //fields have their getters as well 
    Set<Right> allRights; 
    Type participantType; 
    Set<Right> allowedRights; 

    public Profile(Set<Right> allRights, Type participantType) { 
     //Set values in fields here 
    } 

    //This is used by UI to show admins which Rights can be altered for creating a new Role. 
    public Set<Right> getEditableRights() { 
     getAllRights - participantType.getRights 
    } 
    public Set<Right> setAllowedRights(Set<Right> addedRights) { 
     //addedRights here is a subset of Rights given by getEditableRights() 
     this.allowedRights = participantType.getRights + addedRights; 
    } 

} 

moins signifie que l'opération de différence Set, Set Union signifie plus ici.

Les droits par défaut pour un Type ne sont pas donnés dans getEditableRights() mais ils sont utilisés pour régler les allowedRights totaux dans setAllowedRights(Set<Right> addedRights)

Pourquoi ai-je créé un IProfile?

Si vous voulez créer un autre type de Profile qui est composé de plusieurs autres classes, lorsque vous aurez Type et dire Reputation (réputation donnera également l'utilisateur un ensemble fixe de droits), alors vous pouvez simplement mettre en œuvre IProfile d'une manière différente et votre code dépendant de IProfile fonctionne toujours de la même manière.