Multiple user mapping challenge, without an AD.

Question

Dear IdM gurus,
I have a challenging situation here and was wondering whether anyone else has made experiences with it.
We have the usual collection of ERP ABAP systems + BW + BI Portal + some non-SAP systems which we want to connect to a central IdM. There is however no HR nor org structure data available, nor any legacy CUA used.
Now the bugger is that there is no AD in this network either... The closest thing to it is a Novel directory server for a subset of the users to access their own mails. The rest are authenticated only physically and via their UID + PWD credentials in the local systems.
As a result of this, there are people who have a multiple of different user ID names in each system. Each of them are impacted by at least 2 different UID names. Some of them might even have 5 different UID names for 5 different systems. There is no central system which contains a full set of all UIDs.
A good dose of data cleansing would be the best... but for the ABAP systems and other workflow type of topics and time pressure this would be rather disruptive to the running systems.
What I have seen discussed before is creating an "AccountName" ATTRIBUTE for each of the respositories and then overwriting the IdM MSKEYVALUE with it (if found) when provisioning a role or password to that repository.
I have however not been able to find any documented solutions relating to this, nor any API available for it either?
I am also wondering what the "gotchas" are, from anyone who had done this already? (Like delta jobsfor loading new data from managed systems, or subsequent unique UIDs whose names might collide with the AccountName attribute of an old UID, or impacts later on for SAML 2.0 Single-Sign-On, etc).
Cheers,
Julius

Answer 1

Hello Julius,
<br/><br/>
that is quite a challenge you got there. But there a several things you can do.
How many systems (including different clients) do you have? Maybe you could also start with a subset of the ABAP-systems, too.
<br/><br/>
First of all is the question, what is the leading system for the creation of users by now. If possible, put the IdM in charge of that in the future. Hopefully everyone agrees on that.<br/>
So you have done the Initial Load and there a several tables in the database with all users and their UIDs of each system. You need now to figure out how the persons and their users in the IdM shall be created and how the individual accounts of each persons will be consolidated. <br/>
If possible, make an Excel list of persons with their usernames in all systems. OK, it would be sure annoying to everybody, to fill out excel list, but that would be the easiest way for you, and the savest. Even if you could only gather 50% of all employees that's quite a bunch then.<br/>
If this is not or only partly possible, figure out how at least, let's say, 99% can be merged correctly. Firstname, lastname, mail is a good start. More attributes can be cost center personal number, company address, telefon number not to forget.
Then I would write me a script or better an sql statment for a view, which tries to merge the user accounts into one person each. Not easy and time consuming in additon, but I guess that's worth it.<br/><br/>
Then create the users. The ACCOUT<system name> atributes, which are created in the ToIdentityStore passes of each Initial Load of each target system hold all account names of a person. Thee will no need to change these. What you need to do for the MSKEYVALUE of the IdM to ensure that there are no problem, is as follows. Define a hierarchy of all systems. You mentioned the edirectory. I would place it in the first position. Then descending depending on the importance in the company and/or number of users.<br/>
Why you need this? Well, assume there is a user named millera in ERP and one in BW, but they are not the same person. If your hierarchy says ERP before BW, the millera of the ERP will be the MSKEYVALUE of that person. The MSKEYVALUE of the other millera has to be set to a different username. For this, you have to detect if the BW millera has another username avaliable, if so, check if this can be the one for the MSKEYVALUE. The fallback strategy for the initial creation of the MSKEYVALUE of all existing users in the IdM as well as of the MSKEYVALUE of all future person would be like: Built a view upon all user tables AND the SENTRIES (and OENTRIES if you want to cover all "deleted" persons) view MSKEYVALUEs (of persons, requests for persons, pendings on persons, etc.). In this view there are now all usernames. Combine them, in that view, with the repository. During the initial writing of users in the Identity Store use this view to check the names.<br/><br/><br/>
A wee bit easier is the creation of completly new employees. Use a rule (script-based!) to create the username, with a combination of surname, givenname and middlename and if needed numbers, or whatever comes to your mind. During the creation script do a check on the view created. If that username already exists continue the script. Oh, and take care of lastnames of nobels like "von, van, del, dos, ..." or double names, wtc. Not to mention umlaute, graves, accents or even chinese, cyrillic or other nice things which can mess up the creation of users in the target systems.<br/><br/>
One last hint: Use the test mode check box in the ToIdentityStore pass(es) to avoid creation of users, etc. in the Identity Store until everything is fine.<br/>
I do not know if anyone found a better solution, but that should be a good plan to start upon.<br/><br/>
Best regards<br/><br/>
Dominik
Edited by: Domink Trui on Dec 19, 2009 4:49 PM
Since when do we need to use < br / > to insert a new line?