Roles
Roles provide a way of assigning requirements for a set of users. They are a part of a role-based access control system, along with segregation of duties rules.
Information regarding the role is defined in the following tabs:
General | Contains role ID, description, status of the role, number of users who are configured with the role, and segregation of duties rules to which the role belongs. |
Authorization | Defines the authorization requirements for the assignment of a role – how many authorizers, and which authorizers. You can also define how many authorizers must deny the request for the assignment to be denied. |
Entitlements | Defines which resources are considered part of the role; the entitlements can be mandatory or optional and can include template accounts, managed groups, and sub-roles. |
Users | Contains a list of users that the role has been explicitly provisioned for. There may be users who meet the requirements of the role but for whom the role was not explicitly provisioned. These users are not considered members of the role. The information on this page is automatically generated. |
Role enforcement | The role enforcement engine can identify users who have excessive or insufficient access according to their role and issue workflow requests to correct the variance. This tab allows you to set role-level enforcement settings, and generate reports. |
Assignment | The automatic assignment engine can provision or deprovision users from a role depending on their membership in a user class. This tab allows you set automatic assignment setting, define or attach a user class and generate surplus and deficiency user reports. |
Role status
When creating a role you must set its status. For a role to be used it must be enabled. For a role to be provisioned during a request to create a new user, the role must be assignable. So, if a role is:
Enabled: the role is active, but can only be provisioned as a sub-role of another role.
Enabled and assignable: the role is active, can be provisioned as a sub-role of another role, and can be assigned to a user during a ”new user create” request or ”modify user” request.
Once created, a role can only be deleted if it has not yet been used (or assigned). Otherwise, it can only be deprecated.
Role necessity
When defining a role’s resource entitlements, you must specify whether the resource entitlement is:
Required | The user must have the resource. When assigning the role to the user, the user is automatically provisioned with the resource. |
Optional | The user can have the resource, and if they do, the resource is considered as part of the role for the user, but the user is not required to have it. When assigning the role to the user, the user is not automatically given the resource; it must be selected during the assignment process. |
Legacy | The user may have the resource, and if they do, the resource is considered as part of the role for the user. When assigning the role to the user, this resource entitlement is not available for assignment and cannot be provisioned for the user. This status is most likely to be applied to a resource entitlement that was required as part of the role at one point in time but now isn’t – it provides historical context for users that were originally given the resource as part of the role. New role members are not assigned this resource. |
Sub-Roles
A role can also be specified as a sub-role of another role. For example, if role A is specified as a sub-role of role B, it means that role B gains role A’s resource entitlements. It also gains any specified authorization requirements inherent in the sub-role or in its constituent resource entitlements. Sub-role membership will not be granted to users; only sub-role entitlements will be provisioned.