From 1+1... to infinity
Imagine you have an application such as Salesforce to connect to your IDaaS solution in order to federate and provision it. To determine the users authorized to access the application and create their accounts, we'll use a Salesforce representative role called "Salesforce".
Now imagine that the application manager asks you to manage the provisioning of assignments to one of the 20 profiles he has configured in Salesforce. We'll use a role representing a Salesforce access, completed by the dedicated profile(i.e. 20 roles): "Salesforce - User", "Salesforce - Buyer", "Salesforce - Sales", "Salesforce - Delivery lead", etc.
Now imagine that the application manager asks you to manage the provisioning of one of the 5 licenses used in Salesforce. This time, we'll use a role representing Salesforce access with a dedicated profile and assigned license(i.e. 100 roles) called: "Salesforce - User - Chatter free", "Salesforce - Buyer - Chatter free", "Salesforce - Sales person - Chatter free", "Salesforce - Delivery lead - Chatter free", etc.
Imagine you had 100 applications to connect with combinations like these. You'd get up to 100,000 roles (probably more than the number of users using the solution).
Now imagine the administrators responsible for managing the platform's performance, the users looking for their role, and the application managers in charge of managing all these roles!
To put a smile back on your users' faces, there's a solution: use Memority and its dimensions!
Dimensions, attributes of assignments
Dimensions are defined by role. This allows you to add information or constraints to user assignments. This information will be defined per user for each assignment. These attributes can be of any type (character string, list of values, organization references, monovalent or multivalent, mandatory or optional) and can be used to define an administration perimeter or information to be provisioned by the application or sent to federated applications.
Let's take our previous example and its 100 Salesforce roles: dimensions drastically simplify the role model, reducing it to a single "Salesforce" role with two dimensions - "Profile" and "License". For each assignment of the role to a user, the user's profile and license can be selected from a list.
The number of roles to be managed is therefore limited.
The benefits are numerous:
- administrators benefit from easier management processes;
- users can search for a single role, without having to ask themselves unnecessary questions;
- application managers can now manage lists of values.
Similarly, it is possible to define the perimeter of administrators' administrative roles in order to set up delegated administration of identities and objects managed within Memority. The Identity Factory, for example, lets you define an "Application Manager" administration role, for which you can specify the applications managed by the administrator. From the Memority portal, he or she will be able to view and manage only the resources and roles attached to his or her applications, and view his or her reporting data: user access, provisioning or assigned roles.
Dimensions + workflows: the winning combo
Dimensions can represent all the attributes required to define an assignment. However, in some cases, the values required may be highly technical or of interest only to an informed public. Dimensions can therefore be calculated to limit user interaction as much as possible, and if selection by an administrator is absolutely necessary, dimensions can be entered when validating assignment workflows.
Let's take the Salesforce example one last time: the application manager would like the Salesforce role to be available for self-service, but without the user having to select a license. In this case, rules can be set up to calculate the required license on the basis of the requested profile, or the license dimension can be entered only by the application manager in the workflow validation stages. The aim is to simplify the user experience as much as possible, and limit input errors.
In the same way, we can precisely define workflow approvers thanks to the scope of administration defined by their dimensions. So, in our example, we use a single "Application Manager" administration role, with a perimeter defining the applications each manager manages. In the workflow, we indicate as approvers the people with the "Application manager" role. The workflow then automatically selects administrators with the right role and scope. This makes it possible to generalize the use of the administration role and workflow for several applications.
Now imagine your administrators, users and application managers!
And if you're still hungry for more, there's one last episode in our series dedicated to role models: recertifying assignments. Stay tuned!
