The Role Model #3 : Dimensions

Episode 3

Memority offers an extremely powerful role model to manage delegated administrative capabilities within the Memority portal, access to applications, hardware assignments, or any other link between an identity and a resource.

So far, in episode 1 et in episode 2, we have seen how roles are defined and the assignment rules we can use to offer them to users. Now, let’s explore one of the core elements of our role model: dimensions.

From 1+1… to Infinity

Imagine you have an application like Salesforce to connect to your IDaaS solution for federation and provisioning. To determine which users are authorized to access the application and create their accounts, we will use a role representing Salesforce called “Salesforce.”

Now, imagine the application manager asks you to manage the provisioning of the Salesforce’s account to one of the 20 profiles configured in the application. We would use a role representing Salesforce access, completed with the dedicated profile (so we will have 20 roles): “Salesforce – User,” “Salesforce – Buyer,” “Salesforce – Salesperson,” “Salesforce – Delivery Lead,” etc.

Now, imagine the application manager asks you to manage the provisioning of one of the 5 licenses used in Salesforce. This time, we would use a role representing Salesforce access with a dedicated profile and an assigned license (meaning 100 roles): “Salesforce – User – Chatter Free,” “Salesforce – Buyer – Chatter Free,” “Salesforce – Salesperson – Chatter Free,” “Salesforce – Delivery Lead – Chatter Free,” etc.

Imagine you have 100 applications to connect with combinations like these. You would end up with up to 100,000 roles (likely more than the number of users using the solution).

Now, think of the administrators responsible for managing the platform’s performance, the users searching for their roles, and the application managers overseeing all these roles!

To bring a smile back to your users, there is a solution: use Memority and its dimensions! 😃

Dimensions: attributes of assignments

Dimensions are defined per role. This allows you to add information or constraints on user assignments. This information will therefore be defined per user for each assignment. These attributes can be of any type (string, list of values, organization references, single or multi-valued, mandatory or optional) and can be used to define an administration scope or information to be provisioned to the application or sent to federated applications.

Let’s revisit our previous example with its 100 Salesforce roles: dimensions drastically simplify the role model by reducing it to a single “Salesforce” role with two dimensions – “Profile” and “License.” For each role assignment to a user, you can choose the user’s profile and license from a list.

Example of a Salesforce role assignment to a user. Here, we see the 2 dimensions License and Profile. These define the information that will be reused during account provisioning

The number of roles to manage is thus limited.
The advantages are numerous:
· Administrators find their management processes easier.
· Users search for a single role without unnecessary questions.
· Application managers now manage value lists.

Similarly, it is possible to define the scope of administrators’ roles to implement delegated administration of identities and objects managed within Memority. The Identity Factory, for example, allows defining an “Application Manager” administrative role where the applications managed by the administrator are indicated. From the Memority portal, the administrator can only view and manage the resources and roles attached to their applications and view their reporting data: user access, provisioning, or assigned roles.

Dimensions + Workflows: the winning combo

Dimensions can represent all the attributes necessary to define an assignment. However, in some cases, the necessary values may be very technical or relevant only to a specific audience. Therefore, dimensions can be calculated to minimize user interaction. If administrator selection is necessary, dimensions can be entered during the validation steps of assignment workflows.

Let’s revisit the Salesforce example one last time: the application manager wants the Salesforce role to be requestable in self-service but without the user having to choose their license. Rules can be established to calculate the necessary license from the requested profile or reserve the license dimension entry for the application manager during the workflow validation steps. This simplifies the user experience and reduces entry errors.

Similarly, we can precisely define workflow approvers using the administrative scope defined by their dimensions. In our example, we use a single “Application Manager” administrative role with a scope defining the applications each manager oversees. In the workflow, we specify as approvers the people with the “Application Manager” role, and the workflow will automatically select the administrators with the correct role and scope. This generalizes the use of the administrative role and workflow for multiple applications.

Example of workflow implementation for Salesforce assignment. In this one-step approval workflow, the profile is set at role’s request and the license is set at workflow’s approval.

Now, imagine your administrators, users, and application managers.👇

And if you still want more, there’s one last episode in our series dedicated to role models: recertifying assignments. Stay tuned!