SailPoint Create a role

Open Setup, then Roles, and choose the Role Editor. Settle two things first, because both are awkward to change afterwards.

The first is the role type. IdentityIQ ships four: Organizational, Business, IT and Entitlement. For a job function you want to assign to people, you need a business role, and beneath it one or more IT roles that hold the actual access. Nearly every role you create is one of those two.

The second is the name. The name is the key other objects reference, it appears in every certification and request, and renaming later breaks references in rules and workflows. Pick a convention that says which system and which job the role belongs to, and give the display name the words a manager will recognise in a certification.

Create the IT role first. A business role can only require roles that already exist, so building top down means saving an empty business role and coming back, which is where half-built roles come from.

In the editor, choose the IT type, give the role its name, display name and description, and set the owner. Then add a profile. A profile is one application plus a filter on an entitlement attribute: for an Active Directory role that is the application and the group memberships it grants, for a database role it is the application and the roles or privileges. Add one profile per application the role covers. Where the same job needs access in three systems, that is three profiles on one IT role, or three IT roles under one business role. The second is easier to certify and reuse, and it is the usual choice.

Leave the IT role detectable, which is the default. That lets IdentityIQ recognise identities who already hold exactly this access and show the role as detected, which matters in the check at the end.

Now create the business role. Set its type, name, display name, description and owner, then open the role relationships and add the IT role you just built as a required role. Required means assigning the business role assigns and provisions the IT role beneath it. Permitted means the IT role may be requested by people who hold the business role, without being granted automatically, which is the right relationship for access only some people in the job need.

Give the business role a description a requester and a certifier can both understand. It is the text an approver sees, and a blank or technical description is the most common reason roles are waved through unread.

Two routes, and a role can use both.

An assignment rule assigns the business role automatically to every identity that matches. The editor offers several ways to express it: a match list of attribute values, a filter, a population, or a script or rule for anything the others cannot say. A match list on department and job title covers most birthright roles and is the easiest to read in a year's time. Keep the rule on identity attributes that the authoritative source maintains. A rule on an attribute nobody keeps current assigns the role to the wrong people slowly and silently.

Marking the role requestable puts it in the Lifecycle Manager access request catalogue, so people can ask for it and go through the approval and provisioning that Lifecycle Manager runs. Roles for access that only some people in a job need are requestable and not automatically assigned. Roles everyone in a job needs are assigned by rule, and often not requestable at all.

Set the role to enabled. Activation and deactivation dates are there for a role that should only exist for a project or a season, and they are worth using rather than remembering to disable it.

Saving a role can start a role approval workflow, depending on how the system is configured, and until the owner or the role approver acts, the role is not live. Check the work item queue rather than assuming the save took effect.

Once approved, nothing has changed for any identity yet. Role assignment happens during an identity refresh with the option to refresh assigned and detected roles switched on, and provisioning of the access beneath the role happens when the refresh is also told to provision assignments. Run that refresh against a single test identity, or a small population, before the scheduled nightly refresh picks the role up for everyone it matches.

Half an hour, and it is the part most people skip.

1. Before assigning anything, run the impact analysis from the editor. It reports how many identities the assignment rule would match and what provisioning would result. A number far above or below what you expected is a rule problem, and this is the cheapest moment to find it.
2. Pick one identity that should receive the role and one that should not. Run an identity refresh scoped to those two with role assignment on and provisioning off. Open each identity. The first shows the business role as assigned and the IT role beneath it; the second shows nothing.
3. Run the refresh again with provisioning on, for the first identity only. Watch the provisioning plan: it should contain exactly the entitlements in the IT role's profiles, on exactly those applications, and nothing else.
4. Aggregate the target application and open the identity again. The IT role now shows as both assigned and detected, because the entitlements are present. If it shows assigned and not detected, the profile filter does not match what the connector actually returned, and the role will provision on every refresh and never settle.
5. Find an identity who already holds this access without the role. The IT role appears as detected only. That is either somebody who should have the business role, or access that should be removed, and the role you just built is what makes that visible.

Step four is the one that catches real mistakes, because a profile that looks right in the editor and does not match the aggregated attribute values is invisible until an identity is compared against it.

• One IT role per application or one per job. Per application reuses well and produces more roles; per job is fewer objects that carry every system. Per application is the usual answer.
• Required or permitted. Required for what everyone in the job holds. Permitted for what some request. Making everything required is how roles grant more than a job needs.
• Rule or request. Automatic assignment removes tickets and depends on identity attributes being right. Requestable adds a person to every grant. Birthright by rule, exceptions by request.
• Who owns it. The owner receives composition certifications, approval work items and questions. A named manager who understands the job, not the identity team.

• Saving the role and assuming it took effect. Assignment waits for a refresh, and provisioning waits for a refresh told to provision.
• A profile filter that does not match aggregated values. The role provisions on every refresh and never shows as detected. Compare the filter against a real account's attributes.
• An assignment rule on an attribute nobody maintains. The role drifts onto the wrong people with no error.
• Testing with the nightly refresh. A rule that matches five hundred identities instead of fifty provisions five hundred accounts overnight. Refresh one identity first.
• No owner, or the identity team as owner. Certifications route to someone who cannot say whether the access is right.
• Renaming a role in use. The name is the reference. Change the display name instead.

Building one role is an afternoon, and designing a role model that a department can be certified against without role explosion is the part you do in the course. Once the role is live, launch a role membership certification for it, and read the identity refresh workflow for what the nightly run does with the assignment rule you wrote.