MIIS newbie tales (part 2) – desire for uniquity.

Everybody tries to be unique – to be or to do something to make us unique among others. Even if we are not doing this intentionally this just happens. Everybody also has something which identifies them among others, this is our name, hair color, face, character – in real world we are unique because of all these elements combined togheter, but this is not so simple in Identity Management world. Our identity in digital represenation as it is considered in IdM projects is defined by a set of attriubtes, which also makes it unique among other digital identites which are managed in the same organization, but sudenlly we have to create digital representation of our identity in some directory – this can be LDAP directory, database, application etc. In most cases, in such directory we have to obey to some naming rules\conventions which can cause naming conflicts. We can take some steps to minimize the risk of such conflict and we should always consider possibility of such conflict when new identity representation is being created.

For above reasons in almost every IdM project there is a need to generate unique values which has to be used as DN or login names for users – it can be real pain in .$$ to get unique value for attriubte sometime. Because I work mostly with MIIS and other MS technologies I will use MIIS and .NET routines in my examples presented below, but I think that even if somebody who is reading this is not using MIIS, this post can be also considered as more general.

Consider generating SAM account name value for Active Directory users as an example. SAM account name is a name which is used to unique identify the user in AD domain during the logon process etc. You can construct this value based on many different factors, but most common is using surename and givenName of user, with some constraints like:

• maximum length: max length for attribute is 20 characters, but often shorter value is used
• order of elements and number of characters taken from each component of source attributes.

So lets assume that we have to meet following conditions for sAMAccountName value:

• max length: 20 characters
• if surename is longer then 10 characters, we are using first letter of givenname , '.' and surename, in other case we are trying to use givenname + '.' + surename format,
• if generated value isn't unique we can try to make it unique by appendign number from 0-9 at the end of it.

If we have a new value we have to test its uniquity – we can use Utils.FindMVEntries meathod to perform search through metaverse in hunt for duplicated value for newly generated sAMAccountName value (or any other unique value we are searching for like CN) .

Few notes from the field here. For sAMAccountName value You have to remeber to strip any accent characters from this attribute if You can find there any. There are different methds to do this but I learnt simply trick which maybe I will post here if I get permission from its author :).
For CN value accent characters can be used but it should be stripped when we would like to perform search.

What You may want to consider also is a scope of uniqness for our new value – for sAMAccountName we have to make sure that it is unique in whole domain becasue AD will not let us create value which is used by another account. But … if we will take a look at CN value, it doesn't have to be unique in the moment of creation in whole domain, it has to be unique in its container only. Should we take care to make it unique in whole domain? Yes, if we are considerig possibility that object can be moved to other container – it may conflict there with other value.
How we can generate value unique for whole domain usng provisioning code in MIIS extension? We have to have these attributes in metaverse space available in some way because in most cases unique value will be generated in provisioning code, and this is a place where we can search Metaverse space with FindMVEntries. so maybe we should consider projection to metaverse all objects from connected systems (like AD) and their attributes which may be needed to generate unique value, even if we do not manage these objects directly. Just to get their sAMAccountName or CN value in a role of placeholders in some metaverse atribute. To keep it clear we can project these connectors to other class of MV objects then our base objects.

After all, if we have engine to generate unique value for attribute, we have to put this into work with some routine, which will let us judge if generated value is unique – where uniquity terms are defined by ourselvs. In most cases such routine will perform following steps:

1. Generate new value as a proposal
2. Search for this value in metaverse using search logic – this is a place when we can set some terms of uniquity for our solution. If we want to make such search effective we should also remeber to hold in some structure values generated in current provisioning turn, because they will not get exported \ imported in this provisioning cycle. Some structure initialized with our provisioning extension is a good place to hold these values.
3. If value is unique, use it -> If not, go back to step 1 and try to generate new value.
4. If repeating value generation step is not possible bcause we've reached our uniques boundries (we can't add more numbers to generated sAMAccountName because it is getting too long) -> rise an exception.

A the very end, if we have a new name for our digital entity, which we belive should be unique in its new home we can try to export this to its destination. Even if we are strongly convinced that all possible efforts was done to generate new, unique value there can be always conflict at the provisioning\export phase. This is because MIIS lives in "statefull" world, and something can be in connector space which is not present in MV at the time we are performing new object creation.
Because of this we should handle possible ObjectAlreadyExistException with try\catch section:

using Microsoft.MetadirectoryServices;

(...)

try
{
 (...) provisioning code (...)
}
catch(ObjectAlreadyExistExceptione e)
{
 (...) exception handling routine (...)
}

Seems obvious – but will let us handle possible conflicts.
One highlight here – If in exception handling routine new exception will be thrown, please make sure that stack information from original exception is attached in its message. This is extremly helpful later in debugging process.

I think that this is all in this part :). I hope I haven't make any of my readers bored to death :). I know that this topic is covered on MSDN and in developer reference (I think I saw it there), but I've tried to put some my additional thoughts in this post. Maybe it will make somebody's first steps with MIIS and IdM easier.

I think I need some non-technical content in this blog as well – as I'm not only tech guy :). And in the tech area I need some more DS related content as it is still something which keeps me in IT area.

Credits: I wasn't born with this all thoughts and knowledge – which in fact still needs some development to be done – in few places I needed a 'push' in right direction, and I had received so many 'pushes' from two very, very bright guys with whom I have a chance to work togheter. So, Janek and Borys – credits for these post are for both of You!!!