The Memority role model

The Memority role model:
episode 1



Memority offers a powerful role model definition to manage delegated administration into Memority portal but also applications accesses, equipment and any other link between an identity and a resource.

This blog series will allow you to understand how we handled this fundamental part of right management.


As named, Identity and Access Management (IAM) allows to manage inside an organization identities that need to access resources. In the past, authorizations were given with more or less control, with more or less known processes and with more or less painful rights omissions (to add or to remove). To control and simplify authorizations management, it is necessary to define a role model which will allow to set publication rules, access conditions and most important, role removal at the right point!

The role assigns to a user one or more rights about a resource. It allows to define a first level of abstraction and automatism against a technical right and to control that two users with the same roles will have the same rights. But when we need to manage thousands of resources with different types, it becomes necessary to organize and design rights into a role model to manage them as one and allow anyone to request roles easily: the user in self-service, its manager, an application manager and more.

Thanks to role model, it now possible to offers normalized and simple interfaces to users

A very dynamic role model

Memority’s role model is highly dynamic and allows to manage administration rights in Memority, applications accesses, equipment, business roles, contracts and more. In a word, we can represents anything as a resource assigned to a user. To do that, we use several concepts:

  • Resource: the representation of a resource to which we want to get rights (e.g. Memority, ServiceNow, a mobile phone…)
  • Right: the representation of a technical right which links a resource to a role and is used to trigger provisioning or access to an application for example
  • Role: the role that will be assigned to users. It is bind to one or more rights or one or more other roles for a business role
  • Dimensions: additional information or constraints over the right that are set on role’s assignation to a user (e.g. license dimension for Salesforce role). A full article about dimensions is coming 😉

An administration role, the data model allows to define assignation rules, links between resources and rights

Different types of resources and roles

Thanks to these 4 concepts, we can easily design several types of resources and roles to set a dedicated data model, with their own attributes.

For example, we can set resource types “Application” and “Equipment”, and role types “Application role”, “Administration role”, “Business role” and “Supplies” with their own publication and assignment rules (another article about publication and assignment is coming too 😉). These roles can be displayed separately according to their types, and managed by dedicated administrators.

Links between resource types and role types according to our example. These role types are displayed in separated tabs in portals

We set our Memority role model, now we can dig deeper:

  • How to set publication and assignation rules?
  • How to use dimensions?
  • How to recertify user’s roles?

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

Alexandre Pallueau
Latest posts by Alexandre Pallueau (see all)
Scroll to Top