Names

The names of persons is a subject that will impact a provisioning roll out in many ways. Some very upfront and other more convoluted. If you ignore the subject you may regret this once your system is live and the problems starts showing up. Names are not only used to populate the basic name fields but also as generators for things like logins and email addresses so by solving some of the problems up front in the feeds you can avoid a lot of issues in the target systems.

In this posting I will talk about static names while a later posting will discuss name changes.

If you are US based and you are rolling out an employee only system the name seeding is quite straightforward. The HR system usually uses the name that is featured on the social security card so that is the name that gets feed to you. For the last name this is usually straightforward but many people go by a different first name. Their real first name may be "Joseph" but everyone calls them Joe so they want their email to be joe.smith instead of joseph.smith. The solution to this problem is to have a preferred first name field and use that in case it exists.

Next problem comes in form of names that contains weird characters such as O'Malley. Normal solution is to just filter out any non a-z and A-Z characters from the feed. Hyphens are also usually allowed.

Outside of the US problems get worse. You have all kinds of strange characters in names and just filtering away all "strange" characters may not work very well. The happy Swede "Åke Öhlund" would not be so happy with the email "ke.hlund". What I have found is that you can actually support most languages by a simple translation table with about thirty entries that simply drops the umlauts and accent characters and turn them into the corresponding ASCII character. Our friend "Åke Öhlund" would usually like to get the email "ake.ohlund". Or at least he won't complain too loudly.

There a number of national or regional issues that I have run into over the years. If your system will cover these regions it is worth investigating if you will run into this specific issue or not.

In some parts of the world people have more than one last as well as first name. For example among expat Chinese in Singpore it is common that you have an official Chinese name and in addition a western name. A preferred last name as well as preferred first name solves this problem.

In Holland a lot of people tend to start their last name with van as in "van Fleet". There may be a request to generate email addresses with the van removed.

Germans like their formal titles and sometimes the Herr Doctors wants their Doctor degrees to be an integral part of their last name. Don't be surprised if you find "Schmitt, Dr" in the last name field in the HR feed. In severe cases you may even find "Schmitt, Dr, Dr" or "Schmitt. Professor Dr".

In Latin America people usually have two last names as your inherit one last name from your mother and one from your father.

Gartner Magic Quadrants

Gartner has published a new provisioning magic quadrant. In my opinion it is a quite interesting read.

One of the main points is that there has been a shift away from provisioning towards auditing, access recertification (attestation in OIM speak) and governance. Gartner uses the term IAI (Identity and Access Intelligence). The main driver here is the fact that provisioning projects are long, complex and painful while IAI projects are easier and quicker.

In my experience this is a correct observation. The real challenge in provisioning projects is that the provisioning process in an enterprise tends to be quite complex. In many cases the process isn't properly documented or there may be multiple different processes in different parts of the enterprise. The business analyzes work that is needed to document the process can be very time consuming and in many cases important points are missed.

An alternative is of course to simply adopt a "best practice" provisioning process but this requires a lot of political will and in many cases the complexities of the enterprise process is present for a reason.

On the other hand few companies have an established IAI process so adopting the "best practice" is relatively painless. This means that the time consuming step of documenting and implementing the current corporate business process can be almost completely skipped in an IAI project. The integrator can basically use whatever canned approach they happen to have handy which means that results can show up in weeks rather than months (or sometimes even years) which is the time scale you need for a custom provisioning implementation.

IAI projects are usually run to improve security and reach compliance but they can actually result in substantial operational efficiencies as well. In one IAI project we found 100+ user accounts for a quite expensive (1000+ USD per year license fee) application that really weren't needed. The lower license cost was a quite nice bonus for the customer but they actually were even more happy about the fact that we found 600 active remote access accounts that no one could explain who they belonged to.

OIM Howto: Interacting with Tivoli Directory Server

OIM has a quite large list of of connectors but sometimes you need to interact with a target system that lacks a standard connector. One such example is TDS (Tivoli Directory Server).

TDS is used as the internal directory server in TIM and can also be used as a standard corporate directory or as the user directory for the IBM Tivoli Access Manager. It is a standard LDAP v3 compliant directory so in theory you should be able to use any of the LDAP connectors (AD, eDirectory and Sun JDS). I would generally not recommend trying to use the AD connector as it includes a lot of functionality that addresses peculiarities in AD but either the eDirectory or Sun JDS will work fine.

The problems that may force you to write a custom connector will often have more to do with the lack of functionality of the standard connectors than incompabilities between TDS and the connectors. The eDirectory and the JDS connectors have basically gotten minimal updating during the last four years so compared with the AD connector their functional depth is quite limited. One area where you may see compability issues is in the handling of roles and groups.

You may end up writing some custom logic in JNDI to complement the functionality of the standard connector which really isn't very complicated if you have some basic Java programming skills. An example implementation of a JNDI based connector can be found in the JNDI demo tool