The Memority role model #Episode 2: Assignment & Publication

Memority offers a powerful role model to manage either delegated administration rights, application accesses, equipment provisioning or any link between a resource and an identity. This article series will give you keys to understand how we handle this foundational brick of right management.

Previously, in Memority role model series, we talked about role model benefits and the different models we can offer to assign resource’s rights. Once these roles defined, we can assign them to our users to give them accesses to their applications. Several new questions appears here: who can assign which role? To whom? With which condition(s)? To answer these questions, we will use two new concepts here: assignment & publication.

Publication, organization tree of life

To be able to assign a role to a user, we need to publish this role on his security organization. The security organization is an identity attribute which refers to an existing organization in Memority, and which is different from the user’s business organization. Security organizations will be used to have a macro representation of our organization.

For example, have a look to Atlantic company: this company has two subsidiaries, which are split into several entities. In this company – like in thousands others –, some applications will be only available for some subsidiaries, or some administrative roles will be only available for people in specific organizations. Thanks to security organizations, we will be able to model these differences et publish the role only on a specific branch or organization.

As you can see in below picture, security organizations and business organizations can be defined in the same tree, but managed separately. The goal is to determine user’s security organization thanks to his business organization to simplify the user’s management. In this tree, we published a role on Atlantic SA (the role represented by a star is visible and can be assigned to users), but not on Atlantic Ltd (the role is not visible). We can notice that publications are applied by default to all children organizations, so the role is also published on Atlantic Centrale and Atlantic Stores. If we want to publish the role only for some children organizations, we can set a non-publication to explicitly exclude these organizations from the publication.

When a role is not published on an organization, we cannot assign it nor see it in suggested role list. If it is published, then assignment rules will be applied to determine how and who will assign the role.

Organization tree with security and business organizations

Assignment, should I assign or should I not?

The role publication is mandatory for an assignment, but not sufficient. We need to define who can assign the rôle, and to whom. Memority offers a role model already set in its presets defined at tenant creation, but it is possible to override it to fine tune the role model according to your needs!

In this preset rôle model, we offer several options to define assignment conditions to match:

• Self-service request : define if a user can request the role for itself
• Administrator assigner: users with these administrative roles will be able to assign the role
• Approbation workflow: the only workflow to use to approve the assignment, since Memority’s workflow are automatically adapted to the context (for example, to add additional steps in case of self-service request, to skip some steps or to not trigger the workflow on assignment removal).
• If the role can be assigned several times to a user: according to the role model, we can choose one of both options. We will talk about it in next article dedicated to dimensions 😉
• Allowed identity types: only identities with an allowed identity type can be assigned to the role. It can be used to reserve some applications to internal people only for example.
• Roles exclusions: set a segregation of duty and limit toxic role combination.

Example of assignment options configuration

Thanks to all these conditions, we can define fine grain manual attribution rules for a role. But it is also possible to set automatic assignment policy on a role to mass assign it to users, without human action – pride and joy for your administrators!

Last item : administrator’s scopes. We wrote before this that a role can be assigned to a user if it is defined as role’s requester, but the role and the user must also be in its administration scope. We don’t want that any application manager can assign any role, but only roles linked to its managed applications. Moreover, we don’t want that any manager assign roles to any identity, but only to identities in its managed organization.

But how to specify that an administrator is responsible for one application without creating as many roles as application? 🤔

Use dimensions! But you have to wait for our next articles of our role model series! 🔜

-> To find out more about the benefits of the Memority platform: click here