Le modèle de rôle Memority : épisode 1

Memority propose un modèle de rôle extrêmement puissant qui permet de gérer aussi bien des capacités d’administration déléguées dans le portail Memority, que des accès à des applications, des attributions matérielles ou tout autre lien entre une identité et une ressource.

Nous vous proposons une série d’articles, pour vous permettre de comprendre comment nous avons géré cette brique fondamentale de la gestion des droits.

Comme son nom l’indique, l’Identity and Access Management (IAM) permet de gérer au sein d’une organisation les identités qui doivent accéder à des ressources. Les habilitations étaient historiquement accordées de manière plus ou moins contrôlée, selon des processus plus ou moins connus et parfois avec des oublis de droits plus ou moins gênants (en trop ou en moins). Pour maîtriser et simplifier la gestion des habilitations, il est important de définir un modèle de rôle qui permettra d’acter les règles de publication, les conditions d’accès et surtout de retrait de ces rôles au moment venu !

Le rôle permet d’assigner à un utilisateur un ou plusieurs droits relatifs à une ressource (#définition). Cela permet de définir un premier niveau d’abstraction et d’automatisme vis-à-vis du droit technique unitaire, et de contrôler a minima que deux utilisateurs ayant un même rôle auront les mêmes droits dans une même application. Mais lorsque l’on doit gérer des milliers de ressources de différents types, il est nécessaire d’organiser et de conceptualiser les droits en un modèle de rôle qui permettra d’avoir un fonctionnement similaire, et de permettre à chacun de faire des demandes facilement : l’utilisateur en self-service, son manager, le responsable applicatif ou d’autres parties prenantes.

Grâce au modèle de rôle, il est possible de proposer des interfaces normalisées et faciles d’utilisation pour les utilisateurs

Un modèle de rôle très ouvert

Le modèle de rôle de Memority est très ouvert et permet de gérer aussi bien des droits d’administration dans Memority, des accès à des applications, des dotations matérielles, des rôles métiers, des contrats, etc. En résumé, tout ce qui peut être représenté comme une ressource assignée à un utilisateur. On utilise pour cela différents concepts :

• La ressource : la représentation de la ressource pour laquelle on souhaite obtenir des droits (par exemple : Memority, ServiceNow, un téléphone portable, etc.)
• Le droit : la représentation d’un droit technique faisant le lien entre une ressource et un rôle permettant de déclencher les actions de provisioning ou l’accès effectif à une application par exemple
• Le rôle : le rôle qui va être assigné aux utilisateurs et comprend un ou plusieurs droits ou un ou plusieurs autres rôles dans le cadre de rôles métier
• Les dimensions : des informations ou des contraintes supplémentaires sur le droit que l’on peut définir lors de l’assignation d’un rôle à une identité afin d’apporter des informations complémentaires (par exemple, la dimension licence d’un utilisateur dans l’application Salesforce). Nous consacrerons un articles dédié aux dimensions.

Visualisation d’un rôle d’administration : le modèle de données permet de définir les moyens d’assignations, le lien avec les ressources et les droits

Différents types de ressources et de rôles

Grâce à ces concepts, il est très facile de définir plusieurs types de ressources et de rôles permettant d’avoir un modèle de données spécifique pour les mettre en place, avec leurs propres attributs.

Par exemple, il est possible de définir des types de ressources « Application » et « Matériel », et des rôles de types « Rôle d’application », « Rôle d’administration », « Profil métier », « Dotation matérielle » et « Contrats », avec leurs règles de publication et d’assignation dédiées (nous consacrerons un autre article de notre série à la publication et aux assignations 😉). Ces rôles peuvent être présentés différemment selon leurs types, et avec des administrateurs différents.

Relations entre les types de ressources et les types de rôles dans notre exemple. Ces différents types de rôles sont présentés dans des onglets différents sur les interfaces

Maintenant que l’on sait définir un modèle de rôles Memority, dans les prochains articles de cette série, nous pourrons entrer dans le détail :

• Comment définir les règles de publication et l’assignation des rôles aux utilisateurs ?
• Comment utiliser les dimensions ?
• Comment recertifier les rôles de nos utilisateurs ?

Pour cela, un peu de patience, et 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