Random Thoughts on IdM

Ash Motiwala and Ian Yip have posted some pretty funny, yet true observations about Identity Management on their blogs lately.  After being challenged by Ash, I came up with a couple.  

Seemed like a fun thing to do right now before the holiday:

• When it comes down to it... all you have is Data, now what you do with it... there's the rub.
• With all due apologies to FDR "We have nothing to fear but the audit itself"
• Again apologies to the late Arthur C Clarke: Any sufficiently advanced IdM Design  is indistinguishable from magic.
• And finally, with respect to Isaac Asimov/Kim Cameron, here are the three laws of Provisioning Systems:

1. A Provisioning system may not injure identity data or, through inaction, allow identity data to come to harm.
2. An Provisioning  System must obey orders given to it by workflow, except where such orders would conflict with the First Law.
3. A Provisioning  must protect its own database as long as such protection does not conflict with the First or Second Law.

My best wishes to all for a happy and safe Thanksgiving holiday here in the US. 

For everyone else, you be safe and enjoy too!

Another Great NW IDM Information Source

SAP's NetWeaver Identity Manager (and MaXware Identity Center before it) is an increasingly popular tool for IdM Implementations.

One of the current drawbacks of the tool is that it does not have a lot of places that you can go to learn about how to use and implement the tool.

Certainly, this blog and the SECUDE Global Consulting Blog have been great public places to read up on the application and its role within the greater framework of Identity Management.

If you have access, SAP's NetWeaver Identity Management forum is probably the best place to ask and answer questions on the product. If you don't have access to this forum, I'd consider getting it. Quickly. It's indispensable to anyone working with the application on a day-to-day basis.

On the free side, SAP does sponsor an NetWeaver IDM blog where various SAP and non-SAP resources discuss Identity Management issues within the SAP and NetWeaver framework. It's a great place to read up on various topics regarding NetWeaver, SAP and Identity related issues.
(Shameless plug: I recently wrote an article there too!)

Enterprise Identifiers

I've been thinking recently about how one should be identified within the enterprise.
It's no secret that there are several identifiers that are used by an organization for identification. Some examples include:

• Government issued numbers - Using identifiers such as Social Security or Driver's license numbers is legal, if not mandatory in some places. These are nice since they don't have to be maintained by private organizations, but this can also present problems, not to mention privacy and legal conflicts.
• Email Address - IDs based on email address offer guaranteed uniqueness, however these can change over time especially with life changes, particularly when they are based on the user's name.
• Name combinations - Creating an ID that is made up of x number of characters from first name and y number of characters from surname has both good and bad points. These are wonderful because they are easy to remember for the end user, however there can be challenges to IT making sure that all IDs are unique.
• Application centric ID's - Some applications create their own sequenced ID's. These tend to be easier for IT and application owners, however they tend not to be as easy for people to remember. They also have the advantage of not revealing too much information about what is behind the login ID in the way of personal information. For instance there's no way for anyone to know that user ID H10032 is really Matt Pollicove (FYI - not my userID) But they can give some basic information by simple formatting, such has having certain characters indicate employment status, whether or not the ID is for a service account, if the account is tied to a particular group or location, etc. However this degree of tight formatting tends to make the user IDs not terribly portable as status changes occur. Once conventions are set for how users are to be identified within the enterprise, some additional challenges depending on how the user entries are used within the enterprise.

Which one is right? Which one is wrong? I don't think there is any one correct answer besides what works for the organization. Certainly from a security and privacy perspective showing less information that more is better but does this really solve anything? Identity information is still exposed via external services such as portals, white pages and other search methods. So even if personal information is abstracted by a different identifier, it can still be determined.