Comment simplifier ce rôle et ce modèle de gestion de la permission?
Je travaille sur une application Web contenant des utilisateurs avec plusieurs rôles et que chaque utilisateur peut effectuer plusieurs opérations, basée sur le rôle de l'utilisateur et le niveau de permission du rôle sur l'opération. Je suis venu avec le schéma suivant.
tilisateurs
+--------+-------------------+
| UserID | UserName |
+--------+-------------------+
| 1 | Alice |
+--------+-------------------+
| 2 | Bob |
+--------+-------------------+
| 3 | Charlie |
+--------+-------------------+
| 4 | David |
+--------+-------------------+
rôles
+--------+-----------------+
| RoleID | RoleName |
+--------+-----------------+
| 1 | Tech_Admin |
+--------+-----------------+
| 2 | Tech_Normal |
+--------+-----------------+
| 3 | Non_Tech_Admin |
+--------+-----------------+
| 4 | Non_Tech_Normal |
+--------+-----------------+
PermissionLevels
+-------------------+----------------------+
| PermissionLevelID | PermissionLevel |
+-------------------+----------------------+
| 1 | Tech_Account |
+-------------------+----------------------+
| 2 | Non_Tech_Own_Account |
+-------------------+----------------------+
| 3 | Non_Tech_Any_Account |
+-------------------+----------------------+
| 4 | Own_User |
+-------------------+----------------------+
Serroles
+--------+--------+
| UserID | RoleID |
+--------+--------+
| 1 | 1 |
+--------+--------+
| 2 | 2 |
+--------+--------+
| 3 | 3 |
+--------+--------+
| 4 | 4 |
+--------+--------+
Commandes
+-----------+--------------+
| CommandID | CommandName |
+-----------+--------------+
| 1 | CREATE_USER |
+-----------+--------------+
| 2 | EDIT_USER |
+-----------+--------------+
| 3 | VIEW_USER |
+-----------+--------------+
| 4 | EDIT_PROFILE |
+-----------+--------------+
| 5 | VIEW_PROFILE |
+-----------+--------------+
| 6 | SUSPEND_USER |
+-----------+--------------+
Rolecommands
+--------+-----------+-------------------+
| RoleID | CommandID | PermissionLevelID |
+--------+-----------+-------------------+
| 1 | 1 | 1 |
+--------+-----------+-------------------+
| 1 | 1 | 3 |
+--------+-----------+-------------------+
| 2 | 2 | 1 |
+--------+-----------+-------------------+
| 3 | 2 | 2 |
+--------+-----------+-------------------+
| 4 | 5 | 4 |
+--------+-----------+-------------------+
Pour la simplicité, je n'ai pas décrit les détails du compte, mais chaque utilisateur appartient à un compte - "Tech" ou "non-Tech". Il n'y a que 1 compte technique dans le système.
Voici des exemples de règles commerciales conformément à la table RoleCommands.
- Tech Admin peut créer des utilisateurs dans un compte Tech.
- Tech Admin peut créer des utilisateurs dans n'importe quel compte non technique.
- Tech Normal peut modifier les utilisateurs du compte Tech.
- L'administrateur non technologique peut modifier les utilisateurs dans leur propre compte non technique.
- Non Tech Normal peut afficher son propre profil - qui de la table signifie que d'autres utilisateurs ne peuvent pas afficher le profil de ce utilisateur.
Lorsque je reçois un nouveau REST API, je vais identifier l'opération basée sur les paramètres de la demande et vérifier si l'utilisateur a la permission d'effectuer les opérations basées sur la table Rolecommands. Cela ressemble-t-il à un raisonnable Conception pour la gestion de rôle et d'autorisation?
Mise à jour
On dirait qu'il y aura trop d'enregistrements dans la table Rolecommands car, pour chaque commande, plusieurs combinaisons avec des rôles et des niveaux d'autorisation seront multiples. Pour un objet donné, il peut y avoir N (par exemple: 10) des statuts dans lesquels l'objet peut être. Je souhaite donner une autorisation de la commande ci-jointe_Object_status1 à un utilisateur afin que l'utilisateur puisse afficher l'objet lorsque son statut est Statut1. Cela explose la table Rolecommands. Quel est le meilleur moyen de simplifier cela?
Cela ressemble-t-il à une conception raisonnable pour la gestion de rôle et de permission?
Le terme "raisonnable" est quelque peu ambigu ici.
Adaptée à l'objectif
Cette conception réalise son objectif. Il permet de déterminer les opérations à tout utilisateur connecté à un objet métier spécifique:
- Les utilisateurs sont identifiés
- Les rôles sont identifiés
- Les utilisateurs sont affectés à des rôles
- Les commandes sont identifiées - apparemment une commande se réfèrent à une opération sur un objet métier (comptes d'utilisateurs dans cet exemple)
- Les niveaux d'autorisation sont identifiés - apparemment, le niveau d'autorisation limite les objets commerciaux gérés dans les commandes.
- Les commandes avec les niveaux d'autorisation sont attribuées à des rôles
Force
Cette conception permet une gestion d'accès facile à jouer au rôle de jour, comme prévu dans les applications commerciales modernes.
Cette conception est flexible. Il permet d'adapter les rôles avec une très bonne granularité afin qu'elle permet d'implémenter toute configuration d'accès possible pouvant être souhaitée (en supposant que le niveau d'autorisation représente de manière appropriée les besoins de la segmentation à ce sujet).
La faiblesse
La construction de rôles nécessite l'entrée explicite de toutes les combinaisons. Cela pourrait être fastidieux, si les commandes ou les niveaux d'autorisation sont trop fins.
Le niveau d'autorisation est commun à tous les objets métier:
- Si vous ne gérez que quelques objets d'entreprise, cela partager des règles d'accès similaires, c'est bon.
- Si vous auriez besoin de règles d'accès au diffenet sur différents objets métier, vous devez ajouter plus de niveaux d'autorisation, avec un risque d'incohérence entre la commande et le niveau d'autorisation.
Au fait, la liste actuelle des niveaux d'autorisation ne couvre pas sans ambiguïté l'ensemble des données: je suggère de renommer "propre" dans "Tech_own" et "Tech" dans "Tech_any". Je comprends que "tout" signifie "tout sauf le sien".
Éditer:
Suite à votre commentaire sur la gestion de plusieurs objets métier, je vous suggère d'ajouter une table d'objet métier et de modifier la table de commande et les niveaux de permission, de sorte qu'ils concernent tous les deux un objet métier.
De cette manière, vous êtes sûr que vos profils relieront toujours des commandes compatibles et des niveaux d'autorisation compatibles: il vous suffit d'introduire l'identifiant d'objet métier dans ce tableau.
Cela ne fera que les rôles plus simples, mais cela ne résoudrait pas seulement votre problème, mais permettrait également d'offrir au gestionnaire de rôle une interface utilisateur agréable pour faciliter l'entrée (toujours choisi parmi les éléments compatibles).
Voici comment je voudrais aborder la situation:
- Vous gardez la table de vos utilisateurs
- Ce que vous considérez comme les rôles sont essentiellement des groupes d'utilisateurs. Donc, nous créons un nouveau groupe de table
- Ce que vous appelez, la permissionLEVEL est l'équivalent des rôles que les membres des groupes peuvent avoir (par exemple, un utilisateur qui est Tech_Admin peut avoir le rôle de Tech_Account et non_tech_Account
- Je remplacerais la table des commandes par une table appelée modules, où il conserve les différents domaines que les autorisations doivent être appliquées (par exemple, utilisateur, profil, rapports, etc.)
- Afin de conserver les autorisations, j'utiliserais l'approche CRUD (CREATE, LIRE, LIVEER, DEMIS). Bien que cela puisse être restrictif, il est souvent utilisé pour la conception des autorisations. Vous pouvez stocker la valeur CRUD soit comme un octet où vous vérifiez les bits ou dans des colonnes séparées.
Nous arrivons ici à une question importante sur votre demande et votre conception: ce qui définit les autorisations pour les commandes? Est-ce que les rôles, les groupes ou l'utilisateur peuvent avoir des autorisations individuelles qui remplacent les autorisations de groupe?
Nous pouvons aller avec les tables suivantes:
Grouppermissions
GPID - ModuleID - CRUD (ou des colonnes séparées pour C-R-U-D)
Rolepermissions
Roleïde - ModuleID - CRUD
Question suivante: Dans votre application, les rôles peuvent-ils exister indépendants pour les groupes? Si oui, les tables ci-dessus suffiront. Sinon, vous avez besoin d'une table pour relier les deux
Groupes de groupes
Grille - Grève - Rolid
Question suivante: Un utilisateur peut-il ne faire qu'une partie d'un groupe ou peut avoir un rôle aussi de manière autonome au groupe S/il appartient-il?
Si le premier, vous avez besoin d'une table comme celle-ci?
GroupesAsutilisateurs
GUID - UserID - Groupid
Si ce dernier, une autre table est requise
Rolesusuants
Ruid - UserID - Rolid
Enfin, si un utilisateur peut avoir un niveau d'autorisations individuel, quelle que soit la participation aux groupes ou aux rôles, cette table est requise.
Modules
MUID - UserID - ModuleID - CRUD
En fonction de la politique concernant la propagation des autorisations, vous pouvez ensuite commencer à vérifier les trois dernières tables et à décider de ce qu'un utilisateur est autorisé à faire.