SailPoint various ways to construct identityName

 Construction of identity name

There are various methods for constructing identity name from an authoritative source.  Each method has its advantages and disadvantages.

The normal construction of an authoritative source is to have the employee number as the identity attribute and a first-last full name as the display attribute.  This is normal and is very helpful in the display of the identity on the main identity warehouse page.  However this has a side effect: the identity name of the user is their display name.  This is because on account creation, the display name informs the identity name.  Hence an issue.  Using the employee number for the display attribute has its own redundancy issues and should be discouraged.

Construction of display name

Some sources do not have a display name field, they might have a first name and a last name field.  In this case you should construct this field using a customization rule.

• Define the Full Name or Display Name field in the schema
• Write a customization rule that pulls the first and last names and returns the full or display name to the attribute.
• Define the new field as the display attribute.

Manipulating the identity name

In order to have the employee number to be used as the identity name instead of the display name, you need to explicitly set the name in the Creation rule of the authoritative source application.  This is also where we typically set the initial password for the identity.  For instance, if the application's name for employee number is FILENUMBER (this is the value for WorkDay typically) then the code would look like this:

 identity.setName(account.getAttribute("FILENUMBER"));

And in fact you could set the identity name to whatever you like here, keeping in mind to make it always unique.  For instance you could include the application name in the identity name:

 identity.setName(application.getName()+

    "-"+account.getAttribute("emplid"));

Or I have also seen:

  identity.setName(account.getAttribute(displayName)+

    "-"+account.getAttribute("emplid"));

SailPoint Identity attribute naming recommendations

 I have seen some very odd names for Identity attributes.

Just as a refresher, Identity attributes are defined in the ObjectConfig-Identity.xml file.

For example:

<ObjectAttribute displayName="Job Title" editMode="readOnly" name="jobTitle"/>

My example doesn't include any source or target definitions.

If you want the field to be searchable, you have two options.  One option is to use one of the extendedNumber values.  If you just check the searchable box in the UI, SailPoint will assign the next available extendedNumber value.  This option is fraught with dangers.  The first danger is that OOTB there are only 10 extended attributes defined in the IdentityExtended.hbm.xml file, so if you exceed 10, you will need to uncomment the 11-20 lines and then create the database table fields.  The second danger is that only 5 of the OOTB extended attributes have indexes defined, so any search on those non-indexed attributes will generate a table scan in the database, affecting performance.  You should define and create these indexes as soon as possible in your installation process.

The second option is to used named columns.  This method is described in the hibernate file and here is where this post is important to apply.  My recommendation is to always use strict and concise camelCase for identity attribute names, which go in the ObjectConfig-Identity.xml and in the IdentityExtended.hbm.xml files.  Here are some naming schemes that have generated terrible results:

All caps like EMPLID

Trailing caps like personID

Leading caps like ADLoginName

Numbers like AS400Login

Pascal Case such as JobTitle

Repeated caps like autoFRActivate

Long long names like ADLastModifiedDatetime

Using underscores (snake case) like job_title

Database keywords or function names.  Here are some I have discovered:

• position

Single lower case values are FINE - emplid, title, these are fine although not very descriptive.

If you want to use "ID" in the description, use "Id" in the name such as personId

Keep it short, keep it simple.  Two words is best: jobTitle, departmentName, adLogin, adGuid, empoyeeId, etc.  Remember that Oracle 12c only allows a 30 character identifier.

When you deploy the hibernate file and then execute the iiq extendedSchema command, the extendedSchema job takes the camel case and splits it into words, like this:

jobTitle       becomes job_title

This is done because database don't normally care about case.  For this same reason, always make your indexes to look like the field name, not like the camelCase.

<property name="jobTitle" type="string" length="450"

  access="sailpoint.persistence.ExtendedPropertyAccessor"

  index="spt_identity_job_title_ci"/>

NOT index="spt_identity_jobTitle_ci"/>

Don't try to create the database scripts on your own, you will likely make a mistake.

End

SailPoint saving AD values as a secondary auth source

 This post is primarily so I remember how I do every client's AD.  The point of saving AD values as Identity Attributes is twofold: first, to indicate if the user has an AD account (this can literally be done for any target, but AD is the one that almost everyone uses for their primary provisioning target).  Second, it allows you the OPTION of saving the values for all time, which would allow you to ensure that no duplicates be created.

 I create 5 Identity Attributes:

adLogin (AD Login) which derives from sAMAccountName

adEmailAddress (AD Email Address) which derives from mail

adDistinguishedName (AD Distinguished Name) which derives from distinguishedName

adUserPrincipalName (AD User Principal Name) which derives from userPrincipalName

adObjuctGuid (AD Object Guid) which derives from objectguid

 Any or all of these can be backed up with a global rule I normally call IdentityAttribute-PersistOldValue whose source is literally return oldValue;

You have to decide on your own which if any are sortable. Make a value sortable if you plan to do a search on it using any search method.

If you use the global rule then your values will not be removed if the user loses their AD Account.  Be careful and aware of this.