Le modèle de rôle Memority #Épisode 2 :
Publication et Assignation
Memority propose un modèle de rôle extrêmement puissant afin de gérer aussi bien des capacités d’administration déléguées dans le portail Memority, des accès à des applications, voire des attributions matérielles ou tout autre lien entre une identité et une ressource. Cette série d’articles va vous permettre de comprendre comment nous avons géré cette brique fondamentale de la gestion des droits.
Nous avons évoqué dans le premier épisode de notre série l’intérêt du modèle de rôle et les différentes représentations que l’on peut proposer pour donner les droits liés à nos ressources gérées. Une fois ces rôles définis, nous allons pouvoir les assigner à nos utilisateurs pour qu’ils puissent accéder à ces ressources. De nouvelles questions se posent alors : qui peut accorder quel rôle ? À qui ? Sous quelle(s) condition(s) ? Pour répondre à ces questions, nous allons vous présenter deux nouveaux principes : l’assignation et la publication.
La publication, auprès de mon arbre d’organisation
Pour pouvoir assigner un rôle à un utilisateur, il faut que ce rôle soit publié sur son organisation de sécurité. L’organisation de sécurité est un attribut de l’identité qui fait référence à une organisation définie dans Memority, différente de l’organisation métier de l’utilisateur, et que l’on peut utiliser pour définir des grandes branches dans notre organisation.
Prenons par exemple la société Atlantic : cette dernière a deux filiales, elles-mêmes divisées en plusieurs entités. Dans cette entreprise – comme c’est souvent le cas –, certaines applications seront uniquement disponibles pour certaines filiales, ou des rôles d’administration seront accessibles uniquement pour des personnes affectées à des organisations spécifiques. Grâce aux organisations de sécurité, nous allons pouvoir représenter ces différences et publier un rôle uniquement sur une branche ou une organisation dédiée.
Comme le représente le schéma ci-dessous, les organisations de sécurité et les organisations métiers peuvent être définies dans un même arbre, tout en les gérant de manière différenciée. L’objectif est de déterminer l’organisation de sécurité d’un utilisateur à partir de son organisation métier et de simplifier ainsi la gestion des utilisateurs. Nous avons ici un rôle publié sur Atlantic SA (le rôle représenté par l’étoile est donc bien visible), mais non publié sur Atlantic Ltd (le rôle n’y est donc pas visible). Nous remarquons que la publication est par défaut appliquée à toutes les organisations filles de celle sélectionnée, le rôle est donc aussi publié sur les organisations Atlantic Centrale et Atlantic Stores. Si l’on souhaite publier un rôle uniquement sur certaines des sous organisations, il est possible de définir une non-publication, c’est-à-dire d’indiquer de manière explicite les organisations pour lesquelles le rôle ne sera pas disponible.
Lorsqu’un rôle n’est pas publié sur une organisation, il n’est pas possible de l’assigner, ni même de le voir dans la liste des propositions. S’il est publié, il faut alors regarder les règles d’assignation pour savoir comment et qui va pouvoir assigner ce rôle.
Arbre des organisations intégrant les organisations de sécurité et les organisations métiers
L’assignation : should I assign or should I not?
La publication d’un rôle sur une organisation est indispensable pour l’assignation, mais elle n’est pas suffisante. Il faut encore décider qui peut donner un rôle, et à qui il peut le donner. Memority propose un modèle de gestion dans ses accélérateurs fournis à la création d’un tenant, mais il est possible d’aller encore beaucoup plus loin pour s’adapter à votre besoin !
Dans ce modèle, nous proposons différentes options afin de définir toutes les conditions d’assignation à réunir :
• Demande de rôle en self-service ou non : permet de définir si un utilisateur peut demander ce rôle pour lui-même.
• Les administrateurs qui peuvent assigner ce rôle : les utilisateurs avec ces rôles d’administration dans Memority pourront assigner ce rôle.
• Le workflow à utiliser pour l’assignation et la modification de l’assignation : un seul workflow, car les worfklows de Memority s’adaptent de manière automatique selon le contexte (par exemple, en ajoutant des étapes supplémentaires en cas de demande en self-service, en sautant au contraire des étapes ou à ne pas déclencher de workflow sur un retrait d’assignation).
• Si le rôle peut être assigné plusieurs fois ou non au même utilisateur : selon le modèle de rôle défini, on peut vouloir choisir l’une ou l’autre des deux options. Nous en parlerons plus longuement dans l’article suivant dédié aux dimensions. 😉
• Les types d’identités qui pourront recevoir une assignation à ce rôle : seules les identités de ces types pourront recevoir les rôles, on peut ainsi réserver des accès à des ressources à des utilisateurs internes par exemple.
• Les rôles qui ne peuvent pas être combinés avec ce rôle : permet de définir une ségrégation des tâches et de limiter les combinaisons toxiques de rôles.
Exemple de configuration des options d’assignation
Grâce à toutes ces conditions, il est possible de définir de manière très fine les règles d’attribution manuelle d’un rôle. Mais il est aussi possible de définir des politiques d’assignation automatique par rôle afin d’assigner en masse ces rôles aux utilisateurs, sans intervention humaine – pour le plus grand bonheur de vos administrateurs !
Il reste un dernier point à aborder : le périmètre de nos administrateurs. Nous avons précisé plus haut qu’un rôle peut être donné par un administrateur s’il est défini comme demandeur pour ce rôle, mais il faut aussi que ce rôle et le bénéficiaire se situent dans son périmètre d’administration. En effet, nous ne souhaitons pas que tous les responsables d’application puissent assigner tous les rôles, mais seulement ceux concernant les applications qu’ils gèrent. De même, nous ne souhaitons pas que tous les managers puissent assigner des rôles à toutes les identités, mais seulement à celles qui se trouvent dans les organisations qu’ils gèrent.
Mais alors, comment spécifier qu’un administrateur est responsable d’une application en particulier sans créer autant de rôle qu’il n’y a d’applications ? 🤔
En utilisant les dimensions ! Pour en savoir plus, rendez-vous au prochain épisode de notre série dédiée aux rôles !… 🔜
-> Pour en savoir plus sur les bénéfices de la plateforme Memority : cliquez ici
