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 logging best practice

SailPoint recommends using the log4j calls for logging.  This is in contrast to the occasional use of commons logging in some of their codes.  Just for reference:

import org.apache.log4j.Logger;

Logger alog=Logger.getLogger("com.sailpoint.class.module");

The above creates the Logger class and uses log4j (BEST)

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

Log alog=LogFactory.getLog("com.sailpoint.class.module");

The second example uses the commons logging and is not best, but works.  Commons logging actually uses log4j so it's a needless extra layer.

Providing proper construction, level, and content for log statements is important.  Why do we use logging instead of a debugger? Because for most web applications, you can't pause the program to inspect its variables.  Logging is the best option. 

Some people, generally those who don't understand log4j, will start with a statement like:

log.error("I am here");

and then later something like:

log.error("Now I am here");

Let's examine the errors in this method of troubleshooting:

1) Use of an OOTB log object.

2) Using error call for simple debugging.

3) General lack of information about "where" you are in the program.

4) Lack of any meaningful information in the log output.

In more detail:

1) Never use an OOTB log object, always create a new one.  I always call mine alog but you could call your blog or clog, go nuts.  I have seen plogger and others, but I don't like to type so alog fits my style.  You could overwrite log also but I don't recommend that.

2) Learn the log levels and their meaning.  TRACE is the most verbose and should be confined to inner loops in iterative code, that you would expect to print if there is a very insidious logic issue you are trying to track down.  DEBUG is best for debugging code and should be used for most log statements.  INFO is rarely used but could be used for method entry statements. WARN is the first level of statements that the OOTB log setup will always print, and should be a warning. ERROR should be used in catch blocks and anywhere a severe error is found.  Their respective methods, trace(), debug(), info(), warn(), and error() send this data to the logger.  You have to learn how to set the log levels in the log4j2.properties file (or log4j.properties for older versions).

3) In the text of your log statement, provide a coded prefix or "tag" that indicates the initials of the client, a 3 or 4 character module code, and a unique number.  For example, for Acme's WorkDay customization rule, the prefix on the first log statement will be something like "ACM-WDC-001" and the final logging would be something like:

String fileNumber=(String)object.getAttribute("FILENUMBER");

alog.debug("ACM-WDC-001 Entered WorkDay Customization rule for user "+fileNumber);

Each different module has a unique 3 or 4 character module code and each log statement has a unique number, which does not have to be strictly sequential.

4) Notice above that the log statement contains information about what is happening, rather than just a dead line "I am here".  Always try to include data and don't forget to null check things before printing.

Use of these techniques also makes troubleshooting with your SIEM more effective.