Memority offers an extremely powerful role model for managing delegated administration capabilities in the Memority portal, as well as access to applications, hardware allocations or any other link between an identity and a resource.
We've put together a series of articles to help you understand how we've managed this fundamental aspect of rights management.
As its name suggests, Identity and Access Management (IAM) is used within an organization to manage the identities required to access resources. Historically, authorizations were granted in a more or less controlled way, according to more or less known processes, and sometimes with more or less embarrassing oversights of rights. To control and simplify the management of authorizations, it's important to define a role model that will make it possible to record the rules for publication, conditions of access and, above all, withdrawal of these roles when the time comes!
A role allows you to assign one or more rights to a resource to a user (#definition). This defines a first level of abstraction and automatism with regard to unitary technical rights, and controls at least that two users with the same role will have the same rights in the same application. But when you have to manage thousands of different types of resources, you need to organize and conceptualize rights in a role model that will ensure similar operation, and enable everyone to make requests easily: the self-service user, his manager, the application manager or other stakeholders.
A very open role model
Memority's role model is very open , allowing you to manage administration rights within Memority, access to applications, hardware allocations, business roles, contracts, etc. In short, anything that can be represented as a resource assigned to a user. In short, anything that can be represented as a resource assigned to a user. Different concepts are used for this purpose:
- Resource: the representation of the resource for which you wish to obtain rights (e.g. Memority, ServiceNow, a cell phone, etc.).
- The right: the representation of a technical right linking a resource to a role, enabling provisioning actions or effective access to an application, for example.
- Role: the role assigned to users, comprising one or more rights, or one or more other roles in the case of business roles.
- Dimensions: additional information or constraints on the right that can be defined when assigning a role to an identity, in order to provide additional information (for example, a user's license dimension in the Salesforce application). We will devote a separate article to dimensions.
Different types of resources and roles
Thanks to these concepts, it's very easy to define several types of resources and roles, allowing you to have a specific data model to implement them, with their own attributes.
For example, it's possible to define "Application" and "Hardware" resource types, and "Application Role", "Administration Role", "Business Profile", "Hardware Staffing" and "Contracts" roles, with their dedicated publishing and assignment rules (we'll devote another article in our series to publishing and assignments 😉 ). These roles can be presented differently depending on their type, and with different administrators.
Now that we know how to define a Memority role model, the next articles in this series will go into more detail:
- How to define publishing rules and assign roles to users?
- How to use dimensions?
- How do we recertify our users' roles?
So please be patient, and look forward to the next episode in our series dedicated to roles!
