Le modèle de rôle #3 : les dimensions

Épisode 3

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

Dans l’épisode 1 et l’épisode 2 de cette série, nous avons vu comment sont définis les rôles et les règles d’assignation qu’il est possible de proposer (ou non) aux utilisateurs. Découvrons à présent l’un des éléments centraux de notre modèle de rôle : les dimensions.

De 1+1… à l’infini

Imaginez que vous ayez une application telle que Salesforce à raccorder à votre solution IDaaS afin de la fédérer et de la provisionner. Pour déterminer les utilisateurs autorisés à accéder à l’application et créer leur compte, nous allons utiliser un rôle représentant Salesforce appelé « Salesforce ».

Imaginez à présent que le responsable d’application vous demande de gérer dans le provisioning les assignations à l’un des 20 profils qu’il a configurés dans Salesforce. Nous utiliserons un rôle représentant un accès Salesforce, complété du profil dédié (soit 20 rôles) : « Salesforce – Utilisateur », « Salesforce – Acheteur », « Salesforce – Commercial », « Salesforce – Delivery lead », etc.

Imaginez désormais que le responsable d’application vous demande de gérer dans le provisioning l’attribution de l’une des 5 licences utilisées dans Salesforce. Nous utiliserons cette fois un rôle représentant un accès Salesforce avec un profil dédié et une licence attribuée (soit 100 rôles) appelés : « Salesforce – Utilisateur – Chatter free », « Salesforce – Acheteur – Chatter free », « Salesforce – Commercial – Chatter free », « Salesforce – Delivery lead – Chatter free », etc.

Imaginez que vous ayez 100 applications à raccorder avec des combinaisons telles que celles-ci. Vous obtiendrez jusqu’à 100 000 rôles (sans doute plus que le nombre de vos utilisateurs utilisant la solution).

Imaginez maintenant les administrateurs responsables de la gestion des performances de la plateforme, les utilisateurs à la recherche de leur rôle et les responsables d’applications en charge de la gestion de l’ensemble de ces rôles !

Pour rendre le sourire à vos utilisateurs, il existe une solution : utiliser Memority et ses dimensions ! 😃

Les dimensions, attributs des assignations

Les dimensions sont définies par rôle. Cela permet d’ajouter des informations ou des contraintes sur les assignations aux utilisateurs. Ces informations seront donc définies par utilisateur pour chacune des assignations. Ces attributs peuvent être de tous types (chaîne de caractère, liste de valeurs, références d’organisation, monovalué ou multivalué, obligatoire ou optionnel) et être utilisés aussi bien pour définir un périmètre d’administration ou des informations à provisionner auprès de l’application ou à envoyer aux applications fédérées.

Reprenons notre exemple précédent et ses 100 rôles Salesforce : les dimensions permettent de simplifier drastiquement le modèle de rôle, en le réduisant à un seul rôle « Salesforce » avec deux dimensions – « Profil » et « Licence ». Pour chaque assignation du rôle à un utilisateur, on peut choisir parmi une liste le profil de l’utilisateur et sa licence.

Exemple d’assignation d’un rôle Salesforce a un utilisateur. On voit ici les deux dimensions Licence et Profils. Elles permettent de définir les informations qui seront réutilisées lors du provisioning du compte.

Le nombre de rôles à gérer est donc limité.
Les avantages sont nombreux :
· les administrateurs voient leurs processus de gestion facilités ;
· les utilisateurs recherchent un rôle unique, sans se poser de questions inutiles ;
· les responsables d’applications gèrent désormais des listes de valeurs.

De la même façon, il est possible de définir le périmètre des rôles d’administration des administrateurs afin de mettre en place une administration déléguée des identités et des objets gérés au sein de Memority. L’Identity Factory permet par exemple de définir un rôle d’administration « Responsable d’application » pour lequel on indiquera les applications gérées par l’administrateur. Depuis le portail Memority, il pourra voir et gérer uniquement les ressources et les rôles rattachés à ses applications et visualiser ses données de reporting : accès des utilisateurs, provisioning ou rôles assignés.

Dimensions + workflows : le combo gagnant

Les dimensions peuvent représenter tous les attributs nécessaires à la définition d’une assignation. Cependant, dans certains cas, les valeurs nécessaires peuvent être très techniques ou concerner uniquement un public averti. Les dimensions peuvent donc être calculées pour limiter au maximum les interactions avec les utilisateurs, et si une sélection par un administrateur est absolument nécessaire, les dimensions peuvent être saisies lors des validations des workflows d’assignation.

Reprenons une dernière fois l’exemple de Salesforce : le responsable d’application souhaite que le rôle Salesforce puisse être demandé en self-service, mais sans que l’utilisateur n’ait à choisir sa licence. On pourra alors établir des règles permettant de calculer la licence nécessaire à partir du profil demandé, ou encore réserver la saisie de la dimension licence au responsable d’application lui-même dans les étapes de validation du workflow. Ceci pour simplifier au maximum l’expérience utilisateur et limiter les erreurs de saisies.

De la même manière, nous pouvons définir avec précision les approbateurs des workflows grâce au périmètre d’administration défini par leurs dimensions. Ainsi dans notre exemple, nous utilisons un seul rôle d’administration « Responsable d’application » avec un périmètre définissant les applications que chaque responsable gère. Dans le workflow, nous indiquons comme approbateur les personnes ayant le rôle « Responsable d’application ». Ensuite, le workflow va automatiquement sélectionner les administrateurs disposant du bon rôle avec le bon périmètre. Cela permet de généraliser l’usage du rôle d’administration et du workflow pour plusieurs applications.

Exemple de tâches d’approbation du workflow d’assignation de Salesforce. Dans ce workflow à 1 étape d’approbation, le profil est défini à la demande du rôle et la licence lors de l’approbation du workflow.

Imaginez à présent vos administrateurs, utilisateurs et responsables d’applications ! 👇

Et si vous en voulez encore, il reste un dernier épisode de notre série dédiée aux modèles de rôle : la recertification des assignations. Restez connectés !