A Role Request always originate from a Requester Actor and deal with the following aspects:
-
Actors (the actors involved in the request)
-
Requester (identity requesting the Role)
-
Requestee (identity for which the Role is requested)
-
-
Role (the role being requested)
-
Organization (the organization of the Requestee)
To handle simple and complex role request models, Memority introduces the notion of role publication and role policies.
Publication allows to associate a role and an organization (HR, Operational, Geographic Organization, etc.) to configure if the role can be requested, updated, or revoked for a user that belongs to an organization.
With this model, or a given role, there could have several publications:
-
One to authorize the request, the update, and the withdrawal of the role for an organization A and the BUs which are under this organization
-
One to explicitly forbid the update of the role for a specific BU C (located under organization A)
Thus, the role would be:
-
requestable for identities attached to organization A or to one of the BUs under organization A
-
modifiable for identities attached to organization A or to one of the BUs under organization A, except for the identities attached to BU C
-
removable for identities attached to organization A or to one of the BUs under organization A
The other concept we introduced in the role request mechanism is the Role Request Policy. This concept is used to configure the requester and validation parts of the requests. Therefore, Role Request Policy allows to configure:
-
Request strategies meaning who are actors who have the right to request it: End user, Manager, Application manager...
-
Workflow strategies for each operation meaning which workflow will be used for validation (optional)
