Memority offers an extremely powerful role model for managing delegated administration capabilities in the Memority portal, access to applications, hardware allocations or any other link between an identity and a resource. This series of articles will help you understand how we have managed this fundamental aspect of rights management.
In the first episode of our series, we discussed the benefits of the role model and the different representations we can propose for assigning rights to our managed resources. Once these roles have been defined, we can now assign them to our users so that they can access these resources. New questions then arise: who can grant which roles? And to whom? Under what conditions? To answer these questions, we' re going to introduce two new principles: assignment and publication.
Publishing to my organization tree
In order to assign a role to a user, the role must be published to the user's security organization. The security organization is an identity attribute which refers to an organization defined in Memority, different from the user's business organization, and which we can use to define major branches within our organization.
Let's take the Atlantic company as an example: it has two subsidiaries, themselves divided into several entities. In this company - as is often the case - certain applications will only be available to certain subsidiaries, or administrative roles will only be accessible to people assigned to specific organizations. With security organizations, we'll be able to represent these differences and publish a role only to a dedicated branch or organization.
As shown in the diagram below, security organizations and business organizations can be defined in the same tree, but managed differently. The aim is to determine a user's security organization from his or her business organization, thus simplifying user management. Here we have a role published on Atlantic SA (the role represented by the star is therefore visible), but not published on Atlantic Ltd (the role is therefore not visible). Note that by default, publication is applied to all the child organizations of the one selected, so the role is also published on Atlantic Centrale and Atlantic Stores. If you wish to publish a role only on some of the sub-organizations, you can define a non-publication, i.e. explicitly indicate the organizations for which the role will not be available.
When a role is not published on an organization, it is not possible to assign it, or even to see it in the list of proposals. If it is published, you need to look at the assignment rules to find out how and by whom the role can be assigned.
Should I assign or should I not?
Publishing a role on an organization is essential for assignment, but it's not enough. You still have to decide who can assign a role, and to whom. Memority offers a management model in its gas pedals for creating a tenant, but it's possible to go much further to adapt to your needs!
In this template, we offer various options for defining all the assignment conditions to be met:
-Self-service role request or not: defines whether a user can request this role for himself.
-Administrators who can assign this role: users with these administration roles in Memority will be able to assign this role.
-The workflow to be used for assigning and modifying the assignment: a single workflow, as Memority's workflows adapt automatically to the context (for example, by adding extra steps in the case of a self-service request, by skipping steps or by not triggering a workflow when an assignment is withdrawn).
-Whether or not the role can be assigned several times to the same user: depending on the role model defined, you may wish to choose one or other of the two options. We'll talk more about this in the following article on dimensions 😉
-Identity types that can be assigned to this role: only identities of these types can receive roles, so you can reserve access to resources for internal users, for example.
-Roles that cannot be combined with this role: allows you to define a segregation of duties and limit toxic combinations of roles.
Thanks to all these conditions, it' s possible to define the rules for manual role assignment in a very precise way. But it's also possible to define automatic assignment policies by role, so that these roles can be assigned to users en masse, without human intervention - much to the delight of your administrators!
There's one final point to address: the scope of our administrators. We mentioned above that a role can be given by an administrator if he or she is defined as the requester for that role, but the role and the recipient must fall within the administrator's scope. Indeed, we don't want all application managers to be able to assign all roles, but only those concerning the applications they manage. Similarly, we don't want all managers to be able to assign roles to all identities, but only to those within the organizations they manage.
But then, how do you specify that an administrator is responsible for a particular application without creating as many roles as there are applications? 🤔
By using dimensions! Find out more in the next episode of our series dedicated to roles! ... 🔜
