Working with Roles
If your org has Provisioning enabled, you can use roles to bundle related access and easily grant that access to the identities who need it. For example, you can create a role named Accountants, specify the access to be granted by the role, and identify which users function as accountants in your company and should be granted the access this role provides. When those identities get the access granted by the role, they are also granted access to the source accounts and apps associated with the access profiles bundled in the role.
To enable others in your organization to work with roles, you can grant individuals role admin or role sub-admin user levels. Role admins can create, manage, and edit roles. Role sub-admins can perform these role actions only for roles with access profiles on sources that are associated with the governance groups they are members of.
When access requests are enabled for a role, managers can request the removal of requested roles and the access granted through those roles. Review Enabling Role Removal Requests for details on configuring an approval process for role revoke requests.
You know your organization's sources and their capabilities.
Creating a role requires you to define membership criteria, select the access to be granted by the role, and then update the related identities.
When you give identities a role and update their access, IdentityNow applies these access profiles to the role so identities have access to the sources associated with the access profile.
To create a new role:
Go to Admin > Access > Roles and select New.
Enter the name and description for the new role. If your site has the Access Request or Certifications service, be sure the names and description of your roles are user friendly. Roles need to be descriptive and easy to understand. Easy-to-understand names help reviewers understand the roles, make good decisions about specific roles, and improve the accuracy and quality of the access granted.
Select Continue. to display the new role's Configuration page displays.
Select an identity from the Role Owner dropdown list. The selected identity should be familiar with the role requirements, because they will be responsible for maintaining the role.
Click Save to create the role.
Now you can define who should be granted the role.
To define the membership criteria for the role:
Select the Membership tab to display the Define Membership Criteria panel.
When you’ve finished defining the membership criteria for the role, select Save to save your changes.
Now you can specify the access granted by the role.
To add access profiles to the role:
Go to the Access tab.
In Add Existing Access Profile, search for applicable access profiles and add them to the Access Config panel. As you assign the access profiles, note the following:
- Assign an access profile to either a role or a lifecycle state. Assigning the same access profile to both can cause problems with provisioning.
- Access profiles that are granted to users by roles are not included in certification campaigns.
When you’re finished adding the relevant access profiles, select Save to save your changes to the role.
When you’re ready to use the role in your org, you can enable it and provision the access the role grants to users.
To enable and provision the role:
On the Config tab, select the Enable Role checkbox and select Save.
To immediately provision the access you specified to all users who have this role, select the Update button in the top banner. If you do not select the Update button, these access profiles are provisioned to your users automatically at 1:00 AM UTC.
Wait for the role update to complete (noted by the blue line on the page) before making any changes to the identities associated with this role.
Deselecting Enable Role to disable a role does not trigger provisioning. Identities will keep any access they were granted as a result of this role. Disabling a role this way removes the role from the Request Center and the data evaluation that IdentityNow runs to assign roles.
If an identity has more than one account on a source, you might need to make configurations to individual access profiles to determine which account receives those access profiles when a role is granted to the identity.
To delete a role, select the role from the Roles list and select Delete from the Action menu.
Deleting a role does not remove the access profiles granted to the identities that currently have the role.
Granting Roles Using Standard Criteria
Use the Standard criteria type to determine which identities receive a role. The Standard option consists of a set of criteria or groups of criteria that filter identities based on an identity's entitlements, attributes, sources, or access profiles. Using these criteria, you can create simple filters or extremely granular filter combinations to add identities to a role. For more information, see Standard Role Membership Criteria Options.
Account attributes and identity attributes used as membership criteria for a role must be either string or boolean attribute types. Other attribute types are not supported.
If an account attribute was defined with an integer type when the source schema was defined and you include that attribute when defining the membership criteria for a role, identities with that attribute may not be included in the role.
On this page, use the following tools to determine which identities to add to this role:
Filter - The complete set of groups, criteria, and operators that determines who is added to the role.
Criteria Group - Criteria that are evaluated as a group, using a specific operator. Placing criteria in a group is like placing them inside a set of parentheses.
Criteria - A single rule an identity is measured against. When you're creating criteria, make sure you're grouping the criteria based on the operator you want them to use.
Operator - The way that each criteria is evaluated within a group or between groups, using either AND or OR.
A group can have a single criteria, or it can have many. Each group is combined with the other groups in the filter to create a complete filter.
The criteria you add to a group can be connected by an AND operator or an OR operator. If you want multiple criteria to use the same operator, you can put them in the same group.
You can add as many groups as you want. The operator used between groups is automatically selected based on the criteria you choose to put within groups.
If you choose AND for your Within Groups Operator, your Between Groups Operator is OR.
If you choose OR for your Within Groups Operator, your Between Groups Operator is AND.
Using these tools, you can create a filter to add identities to the role:
From within any new or existing role, go to the Membership tab to display the Define Membership Criteria panel.
Under Criteria Type, select Standard to display the Standard Criteria Builder.
On this page, create a filter that determines which identities are granted this role. Under Operator Settings, choose an operator to use in each criteria group you create. Note that the Between Groups operator can't be edited individually. To globally change the operator, edit the Within Groups operator.
Select Add Group.
In the criteria group, select a type, and fill in all other applicable fields. See Standard Role Membership Criteria Options for a description of each criteria type and the options you have when you've selected it.
To add more criteria within that same group, select Add Criteria. To add criteria that involve using the other operator, create a new group.
To add another group, repeat steps 4 through 6 for as many groups as you want. All groups are evaluated according to the rules you choose.
The filter in the following example grants this role to users in an active lifecycle state who have a manager named Sam Johnson or the entitlement cloud development.
The filter in this next example grants this role to:
Users having cloud development and cloud testing entitlements from the specified source
Users whose department on the specified source contains the words Cloud Test
- Users with only one of the specified entitlements won't receive the role unless they are in a department that contains the words Cloud Test
- Users in the Management department only receive the role if they have the cloud development entitlement and the cloud testing entitlement
Granting a Role Using the Identity List
You might want to grant a role to a specific set of identities. For example, if you are creating a new department at your company and you need to add only users who are joining that department.
To manually create a list by selecting the Identity List criteria type:
Go to Admin > Access > Roles > < Role Name > > Membership.
Under Criteria Type on the Define Membership Criteria panel, select Identity List.
In the Add Identity field, begin typing the name of an identity you want to give the role. Matches appear after you type three or more characters. The first 200 users matching the criteria you enter are displayed in the list.
Select the name of the identity. The identity is added to the Identities list below this panel.
Repeat steps 3 and 4 for each identity you want to grant this role.
You can verify that the correct identities were added to the list of users who have this role on the Identities tab.
Access profiles applied to roles regulate what the identities who have those roles can access and do in their accounts. These access privileges are also known as entitlements.
To edit entitlements for a group of identities assigned to a role, go to Access > Roles and select the role you want to edit.
You can make the following access changes to your role:
- Add a new access profile - Select Add Access Profile and select the access profiles to add to the role. This action provides users attached to the role more account entitlements.
- Remove access profiles - Select the X icon beside the access profile you want to remove. This action removes role entitlements and reduces what users attached to that role can do in their accounts.
To update the role's entitlements, select the Update button in the top banner. Their access also updates automatically at 1:00 AM UTC.
Removing access from a user does not remove any source accounts created as a result of provisioning through the role. To remove the entitlements the role grants the identities, you need to remove those identities from the role, which is described below in Revoking Access Through Roles.
Revoking Access Through Roles
If you have granted entitlements to identities through roles, you can deprovision those entitlements by removing those identities from the roles. This process is also known as revoking a role. Always review the access profiles associated with the role before deprovisioning that access from your users.
Removing access from a user does not remove any source accounts created as a result of provisioning through the role. Role-based deprovisioning only removes entitlements from a user and access to apps.
The method of removing access from users based on their role assignments depends on how they were granted the role.
|Method to Grant Roles||Method to Remove Access|
|Standard Criteria||Change the criteria that must be met to grant the role to users. Users who no longer meet the requirements lose the role. For example, if you want the criteria to stay the same but you want Bob Johnson to lose the role, you can add a new criteria to your filter that says AND Identity Attribute: Name Does Not Equal Bob Johnson.|
|Identity List||On the Define Membership Criteria panel, beside the Identity List, select the X icon beside the user you want to remove.|
The following actions do not result in deprovisioning:
- When an administrator removes access profiles from the list of access granted by the role, those access profiles are not deprovisioned from identities in the role.
- When an administrator deletes an access profile, identities who had that access profile do not lose the related entitlements.
- When an administrator deletes a role, identities who had that role do not lose the related access profiles.
Standard Role Membership Criteria Options
You can create granular criteria to grant a role to your identities. These criteria are based on an identity's attributes and entitlements, allowing you to assign a role only to the specific identities who need it.
Create standard role criteria using any of the following criteria types:
Choose from these criteria types to create groups of criteria. Within each group, you can decide that only one of the criteria need apply (by using the OR operator) or that all of the criteria must apply (using the AND operator). When you choose the operator that applies within groups, the other operator is automatically selected for use between groups.
If the OR operator applies between groups, the criteria from only one group are applied. Since the criteria in that group use the AND operator, all criteria from that single group are applied.
If the AND operator applies between groups, the criteria from all groups ware applied. Since the criteria within that group use the OR operator, only one criteria from each group is applied.
This criteria type filters identities based on whether they have a particular value for an account attribute.
The following options are displayed:
Source - Choose the source that contains the attribute you want to use.
Attribute - Choose the attribute to use. The attribute's Unique ID (UID), name, and description are not available.
Account attributes used as membership criteria for a role must be either string or boolean types. Other attribute types are not supported.
If an account attribute was defined with an integer type when the source schema was defined, and you include that attribute when defining the membership criteria for a role, identities with that attribute may not be included in the role.
- Operation - Select one of the following options:
- Equals - Filters identities for the role if those identities have the selected attribute on the source you chose and it is identical to the value you enter.
- Does Not Equal - Filters identities for the role if the value those identities have for the attribute you've selected on the source is not identical to the value you enter.
- Contains - Filters identities for the role if the attribute those identities have on the selected source contains the value you enter.
- Value - Enter the value you want to use to filter identities by account attribute. This field is not case-sensitive.
Source - Choose the source that contains the entitlement you want to use
Operation - Select one of the following options:
- Equals - Filters identities for the role if those identities have an entitlement identical to the one you choose.
- Does Not Equal - Filters identities for the role if those identities do not have the exact entitlement you choose.
Entitlement - Choose the entitlement you want to use.
If an identity attribute was defined with an integer type when the source schema was defined, and you include that attribute when defining the membership criteria for a role, identities with that attribute may not be included in the role.
Identity attributes used as membership criteria for a role must be either string or boolean types. Other attribute types are not supported.
- Name - Select the technical name of the identity attribute you want to filter on.
Operation - Select one of the following options:
- Equals - Filters identities for the role if those identities have the selected attribute and it's identical to the value you enter.
- Does Not Equal - Filters identities for the role if the value those identities have for the attribute you've selected is not identical to the value you selected.
- Contains - Filters identities for the role if the attribute those identities have contains the value you enter.
Value - Enter the value you want to use to filter identities by identity attribute. This field is not case-sensitive.
If you are filtering on cloudLifeCycleState, you must enter the technical name of the lifecycle state in the Value field.
When you choose the identity attribute manager to add identities to a role, be aware that the manager is also granted the role if a different manager is not listed. If you want to prevent a manager being granted the role, you can add another criteria to the role saying that the user must not have the manager's name, or add a manager to that identity.