4.2 Identity Provisioning Policies

Identity Provisioning Policies

Objective 2.2 asks you to understand identity provisioning policies. In IdentityIQ, a provisioning policy is a list of fields that must have values before a provisioning action can be completed. The fields are presented as a form when a person must answer them. Identity provisioning policies are the ones Lifecycle Manager uses when the target of the action is the IdentityIQ identity itself, not an account on an application.

The Three Identity Policy Types

Configure them on gear icon > Lifecycle Manager > Identity Provisioning Policies:

Two rules to remember:

• If an Update provisioning policy is defined, it overrides the Create policy for identity edits.
• The request cannot complete until the fields required by the policy are included in the generated form and filled in.

The Provisioning Policy Editor: Field Properties

Each field in the policy has these properties:

The matching rule types are FieldValue (default value), AllowedValues (allowed values), Validation, and Owner. They are among the provisioning rule types listed in SailPoint's provisioning summary.

Where Identity Policies Fit in Provisioning

The Create Identity request becomes a provisioning plan that targets IdentityIQ itself. It runs through the process chosen on the Business Processes tab (by default LCM Create and Update). Other provisioning policies apply at plan compilation:

• Application provisioning policies (Create Account, Update Account, and so on, on the application's Provisioning Policies tab) apply when a new account is needed. They can also declare application dependencies, such as an account on application B that needs a value from application A.
• Role provisioning policies remove uncertainty in a role profile. If an IT role's profile is memberOf='Engineering' OR memberOf='Sales', IdentityIQ provisions only the first term by default. A role provisioning policy can specify the value to use instead.

Whatever is still unknown after policies are applied becomes a question on the provisioning project. The Do Provisioning Forms subprocess builds, presents, and assimilates the forms. If a field has an owner, the question goes to that owner, not the requester. Certification remediations, policy-violation remediations, and some provisioning activities cannot present forms. They complete only if no answers are needed, which is normally true for removals.

Worked Example: A Contractor Create Identity Form

Suppose managers onboard contractors directly in IdentityIQ because contractors are not in the HR feed. A practical Create Identity policy might contain:

A FieldValue-style script for the name field could look like this:

import sailpoint.object.Identity;
String base = (firstname.substring(0,1) + lastname).toLowerCase();
String candidate = base;
int i = 1;
while (context.getObjectByName(Identity.class, candidate) != null) {
    candidate = base + i;
    i++;
}
return candidate;

The script can read other form fields as variables named after the fields. For name to recalculate while the requester types, firstname and lastname need Refresh Form on Change (postBack in XML), and the name field must be marked dynamic="true". On a postBack refresh, only dynamic fields re-run their value scripts. One more rule differs between policy types: in application and role provisioning policies, a field that already has a value (literal, rule, or script) is not shown on the form unless reviewRequired is set. Those policies ask people only for what IdentityIQ cannot calculate. After submission, the LCM Create and Update workflow routes approvals and creates the identity. The new identity has no accounts until roles, entitlements, or lifecycle events provision them.

Design Tips

• Put the source of truth in rules. For example, generate the identity name from first and last name with a FieldValue rule so that requesters cannot invent user names.
• Mark sensitive fields as Secret.
• Use Refresh Form on Change for cascading fields, such as a department choice that filters the allowed values for cost center.
• Use field owners for data the requester does not know. For example, security staff can supply a clearance level.
• Prefer Update policies for controlled edits. Include only the attributes managers may change, and make the rest read-only or hidden.