The role model #4 : recertifications

Episode 4

Memority offers an extremely powerful role model for managing delegated administration capabilities in the Memority portal, access to applications, hardware assignments and any other link between an identity and a resource.

In episode 1, episode 2 and episode 3 of this series, we saw how roles are defined and the assignment rules that can be proposed (or not) to users and the dimensions. In this final episode, we’ll look at how role assignments can be maintained over time through recertification.

After modeling your roles to meet the needs of your organization and desired resources, defining your organizations, managing your publications, adding manual and automatic assignment rules, and simplifying role management and user experience through dimensions, you now have an operational role model: congratulations!

Now that our administrators and users can utilize the roles, we need to monitor their usage. In addition to Memority’s reporting capabilities, which allow us to have various views of assignments and their dimensions, we can implement recertification to ensure that these assignments remain up-to-date.

The Defined Role Model vs. Its Actual Usage

Triggering Recertification

As we have seen, the purpose of recertification is to ask a responsible party to recertify a user’s role assignment – that is, to indicate whether the user still needs that role to perform their job or if it can be removed. This is an important aspect of information hygiene, like managing orphaned accounts, to ensure that a user only has the necessary privileges and to avoid the accumulation of roles over the user’s lifecycle.

Therefore, role recertification should be triggered regularly to ensure a cleanup process. There are several ways to trigger recertifications, but it always starts with defining the scope of the recertification. This scope is the intersection of an identity scope (e.g., all internal employees, all identities in the Accounting organization, or all company directors) and a role scope (e.g., all manually assigned roles, roles of an application, or roles tagged as sensitive). You can define as many scopes as necessary to trigger recertifications with deadlines based on the sensitivity of the scope.

Recertification Scopes

Once the scope is defined, recertification can be triggered in campaign mode on a specified date or at regular intervals. All recertifications are then launched for the given scope, which can create bottlenecks for the responsible parties who must validate them.

However, it is also possible to trigger recertifications on-the-fly to smooth out the recertification actions. In this mode, not all recertifications within the scope are triggered simultaneously but individually, based on the specified deadline and the role assignment date for a user. For example, if a role needs to be recertified every six months, recertification will be triggered for User A on July 25th if the role was assigned on January 25th and for User B on September 25th if the role was assigned on March 25th.

The Result of Recertification

Recertification will trigger a Memority workflow to request validation from a designated responsible party. Memority workflows are fully configurable, and approvers are defined by their role according to their management scope (see Article 2 of our series!). Therefore, validation can be requested directly from the identity’s manager or the application owner for a given role.

The approval function is configured directly in the workflow to display useful information for the user’s decision, such as identity attributes, other assigned roles, the recertification history of the role, and dimensions. When the responsible party validates the recertification, they have several options:

• Accept the recertification: Acceptance will be recorded, and the user can continue to benefit from their assignment without any issues.
• Reject the recertification: The rejection will be recorded on the assignment, but the user will still be assigned. This allows for tagging rejected assignments and applying a specific process to them, such as a grace period or a notification to the user to justify the assignment.
• Remove the assignment: The role will be directly removed from the user, who will no longer have access to it.
• Delegate the approval: If delegation has been allowed in the workflow configuration used for recertification, the approver can delegate the task to another administrator according to a predefined scope.

With these various options, it is possible to finely manage the potential outcomes of a recertification to secure users without unnecessarily blocking them.

Thank you for following our series dedicated to role model!
🧐 If you missed the previous episodes, click here:
• Episode 1
• Episode 2 : assignment and publication
• Episode 3 : les dimensions