Bad Data can change sides

Data on the bridge of the Enterprise-D
Image via Wikipedia

I had blogged earlier on the one the issue of the idm one liner I came up with: “Your manual processes are as good as the errors they produce”. Often when my colleagues and I are embarking on an identity management project we  become intimately acquainted with our clients data and manual processes. It is not uncommon for us to find ourselves in a situation where we don’t have good data to work with when doing Identity Mapping. What I mean by good data is: Having user records across target systems that match up on a unique ID across the systems. Think of this as a universal Employee ID number. Now if everyone did this Identity Management integration work would be simple and straight forward. But more often than not integrators have to bend over backwards to figure out how to “map” these records. Let me give you an example. Imagine having 5 Roberts in your Human Resources data (usually your authoritative source).  While they may have unique last names, many people with common first names might have common last names i.e. Robert Thomas. Secondly even these two fields in an environment where there is bad data will have multiple spellings of the name. So Robert can also be Robbie, Rob, R-dizzle. Same goes with Mike, Michael, Mikey etc. If a unique ID number was used across systems these minor spelling mismatches wouldn’t matter because you would just look for a matching ID.
For a target system like Active Directory there is a field called employeeID where you can plug in your universal ID. Many firms setup accounts manually to create a paper trail (firms which have been around since Nineteen Dikkity Two). So all those firms have to do is require including that uniqueID somewhere across each target system. HR usually initiates the requests so that’s the first place one should ensure there are unique records.

So what do you do when you don’t have a unique ID number to map against? You can look for other unique data i.e. e-mail addresses. Or a combination of First Name, Last Name and Middle Name. But when doing a combination of names you have to eliminate possible duplicates. So you would see if there’s multiple people with the same First Name, Middle Name, and Last Name you would exclude them from the process of matching against names or else you might end up mapping the wrong accounts. The effects of incorrect mappings could be devastating. Imagine giving Administrative Rights to an intern or a contractor.

Another way for IT managers to remedy bad data is to get your hands dirty and do what should have been done a long time ago. Manually add the Unique IDs to the records in your other target systems by ensuring you are assigning accounts to the right individuals. This can be a pain, but you have brought this on yourself by not being on top of your data.  Again if these steps could be automated your paper processes (along with the mistakes they bring along with them) could be minimized significantly.  This is a major part of Identity Management which needs to be laid down before provisioning users across systems.

Reblog this post [with Zemanta]
10 Feb 2009

  Username (required)

  Email (will not be published)


Please Note: Your comment will be under moderation. Don't resubmit please. Thank you.