Mon expérience lors de l'expérimentation d'une implémentation RBAC personnalisée est la suivante :
-
Vous lisez une grande partie de la littérature RBAC et pensez la comprendre. Ensuite, vous allez de l'avant et essayez de l'implémenter, juste pour vous rendre compte que vous ne l'avez pas vraiment compris du tout. Finalement, cela aura du sens au fur et à mesure que vous avancerez dans le projet.
-
D'après votre question, vous connaissez déjà le domaine d'activité auquel vous souhaitez appliquer le RBAC. Mais oubliez les objets métier réels pour l'instant. Votre implémentation RBAC doit être générique, ce qui signifie que vous disposez d'un schéma de base de données composé de tables de rôles, d'utilisateurs, d'autorisations, d'opérations, etc. Ensuite, vous aurez des objets qui correspondent à ces tables (relation un à un).
Une fois que vous avez cette implémentation RBAC, elle peut ensuite être modélisée pour pratiquement n'importe quel domaine d'activité, tel qu'un "Département" que vous avez mentionné.
N'oubliez pas que tout n'est pas parfait... J'ai amélioré/modifié/dérivé de la littérature RBAC actuelle afin d'ajouter des fonctionnalités personnalisées, d'améliorer les performances, etc.
Je n'ai pas travaillé dessus depuis un moment, alors j'espère que j'ai raison dans ce qui suit :
- Utilisateur :les instances sont créées et enregistrées dans sa table de sauvegarde.
-
Rôle :les instances sont créées et enregistrées dans sa table de sauvegarde. Les rôles seront attribués aux utilisateurs.
-
Autorisation :une autorisation est essentiellement une combinaison d'une opération sur un objet. Les autorisations sont attribuées aux rôles.
-
Opération :Une opération est simplement tout ce que vous voulez. Cela peut être CRUD (créer, lire, mettre à jour, supprimer) ou cela peut aussi être "imprimer", "rechercher" ou tout ce qu'un humain (ou un système) peut effectuer sur un objet (ou un groupe d'objets).
- Objet :il s'agit essentiellement de tous vos objets qui composent votre domaine d'activité.
Pour encore plus de puissance, vous pouvez implémenter des contraintes pour appliquer une quantité énorme de restrictions diverses.
Avec ce cadre, vous devriez être en mesure de cartographier :
- Qui peut affecter des utilisateurs à un service
- Qui peut les supprimer des services
- Combien d'utilisateurs peuvent être dans un service
- Quel type d'utilisateurs (en fonction des rôles qui leur sont attribués) peut appartenir à un service
- Quels rôles peuvent effectuer quelles opérations dans un service (créer, lire, mettre à jour, supprimer)
- Etc.
