Tu as des utilisateurs qui appartiennent à une société. Ces utilisateurs peuvent avoir des droits sur d'autres utilisateurs de la société. Ils peuvent également avoir des droits sur les ressources (exemple des réservations) appartenant à un pool d'utilisateurs de la société.
Ca c'est pour la base. Si tu veux aller plus loin tu peux:
- avoir des rôles propres à chaque société.
- avoir des droits en plus des droits du rôle attribué à un utilisateur. Par exemple, quelqu'un est manager, il peut réserver dans la politique voyage. Tu souhaites pouvoir lui donner le droit de réserver hors politique voyage, uniquement à lui.
- tu peux créer des groupes pour avoir des droits sur un pool de groupe, qui est compatible avec un pool d'utilisateurs.
Voilà j'ai essayé de te proposer une version simple, et quelques propositions pour challenger un peu ta proposition. Si tu as d'autres idées, libre à toi de les implémenter.
La solution proposée est basée sur les concepts abstraits du Domain Driven Design. On imagine un système RBAC sur un produit de réservation en ligne.
On retrouve deux Bounded Contexts :
- Identity : regroupe les concepts techniques liés à l'authentification et les droits.
- Booking : contient les entités et règles métier liés au produit.
Un User crée une société en est automatiquement admin. Il peut être admin de plusieurs société.
Seul un admin peut ajouter un membre à la société.
Seul un admin peut créer un rôle personnalisé pour la société.
Un admin peut modifier tout rôle de tout employé, manager ou admin.
Un manager ou un employé ne peut modifier le rôle d'aucun autre membre.
Tout membre peut consulter toute ressource liée à la societé.
Les règles applicables disponibles pour un rôle sont read, write et none.
Un Booking est associé à un pool.
Un employé ne peut créer de pool.
Tout membre peut consulter toute ressource liée à un pool.