Too much in the JAR

Recently had a problem where Import/Export was not working.  I kept getting an interesting Error Message:

What was really interesting about this was the user that was referenced, mxmc_admin.  Now this is interesting, because during the Identity Store creation process, you are prompted to use mxmc_rt as the user and there is no time during the install that you are asked to create a JAVA based connection string using mxmc_admin.

This started a great deal of troubleshooting and conversations with people who have a great deal of knowledge with IDM's moving parts. Ultimately we wound up looking at the options in IDM's MMC interface.

The problem was in the Classpath Extension. It seems in this installation we had the old Microsoft SQL 2000 JARs loading before the SQL 2005 JAR. Since the MS SQL 2000 drivers were no longer needed, I removed them, regenerated my dispatcher scripts and restarted the dispatcher services. I was now able to export without a problem. I'm saying it's the order that the JARs are ordered in since I looked at my personal sandbox system and saw that I had the following Classpath: 

And my Import/Export works just fine, thank you very much.

Some more good troubleshooting to come...

Project Listening

At the end of my last post I made a reference to pay attention to the customer's needs when planning and executing an Identity Management project:

...Whether you are a consultant helping a client with their solution or an internal employee building your firm's Identity Management strategy, you still have a client, and their needs should always come first...

I recently took part in a Linkedin discussion where the person posting the question asked the question:

...I would be interested in your take on the latest and greatest products to implement for Identity and Access Management needs across the enterprise. Thoughts / comments...

I gave a pretty straightforward answer which covered some informative (in my opinion) basics centering on looking at the basic systems in the enterprise and advised the questioner to move forward from there.

There were a lot of people who went on another tangent, which was a more consultative answer... Find out what you need and then go to match technology.

Sounds like we have a chicken and the egg here.We cannot determine what technology fits until we determine how the technology is to be used. We also cannot determine how to use the technology unless we know what the technology can do.

Who is right? Who is wrong? I don't think either viewpoint is wrong. The fact is the first questions should have been along the lines of:

• Have you determined use cases?
• Have you begun to look at what technologies are out there?
• Who is using the system?

Nothing about management, systems, or anything else. The initial basic tasks must be this broad outline. Once these big questions are answered we can do to then fill in the holes and determine how to answer all the little questions.

Incidentally, my answer came from the fact that the questioner specifically wanted to know about technology. Since the initial posting he has not made any comments on which approach he needed, but I did see that my good friend and fellow blogger, Matt Flynn posted as well!

The Bigger Picture

In the Identity Management field, there's a lot of thought placed on how to provision users, and even more thought (rightly placed) on de-provisioning users. After all, if users can't get into the systems, you get no return from them since they are not as productive. Similarly, we also know that leaving user accounts active in the system leaves an organization open to data loss, financial and legal risk, and loss of productivity.

However, what of the middle of the user life cycle? User profiles and access need to be maintained as they change titles, departments and locations. It is also important to record this information for compliance/audit reasons.

IdM provisioning tools are probably the best tools for managing these changes in access for enterprise systems. While tools such as SAP's GRC are excellent for work in SAP systems, they are useless outside of them. Same goes for Active Directory / LDAP specific tools, PeopleSoft specific tools, etc. IdM systems have the ability to connect to all of these (and more) systems.

Leave the provisioning, role assignment and management to the IdM system and rely on specialty tools for specialty needs.

New School Identity Management?

I'm all for a discussion of changes in the Identity Management world, in fact I encourage them. I think it's a pretty dynamic world. As Mark Diodati mentions in his article "Changing times for identity management" (login required) There are elements of IdM that are established parts of IT infrastructure, and then there is "New School Identity Management, where he talks about Privileged account Management, AD Bridges and Virtual Directories"

All due respect to Mark, who I know has been around the IdM world for some time, but none of these elements should be considered New School and have been around for quite some time.

• Privileged Account Management - I don't know of an engagement I've worked on in the last 5 years that did not have some concern about the creation and management of both Privileged and Service accounts. If anything, because of their nature, these accounts have a greater need to be created in such a way that they are done according to mandated processes and recorded for audit and review.
• AD Bridges - While not a technology I've gotten to work with a lot I know that many a mixed UNIX/Microsoft shop consider the Vintella/Quest tools to be indispensable.
• Virtual Directories - Again, a technology that's been around for a long time. I've been working with Virtual Directory technologies since 2004, where I would commonly show customers how to map information, provide access controls and even used the Virtual Directory as a write back mechanism to supported repositories.

I can say that I'm glad these Identity Management technologies are finally getting their time in the sun. Some of these technologies have not been considered as interesting or sexy since they worked with a subset of users. I think we can all agree that there are more end users than UNIX accounts or system accounts so they should receive some more attention.

However, in the end, the design and implementation of an Identity Management solution must be holistic in nature. Regardless of one's opinion on the New School qualities of the all the technologies Mark mentions in his article, they must all be considered and planned for in the final design.

The Real Time Myth

I was talking to a colleague last week and the topic of real time provisioning came up.  This has always been a bit of an issue with me due to the use of the term "real time"  I've almost always found that by the time we discuss what is involved in the act of provisioning and what the requirements really are, it is impossible to have this happen in "real time".  The fact is provisioning takes time.  Always has, always will.  Writing the information to your authoritative store takes a certain amount of time.  As does provisioning to LDAP.  We know it takes at least 15 minutes for AD to begin replication, and regardless of type of Directory Service used, it takes time to replicate in an international setting.

In my experience most organizations are more concerned with improving performance over the old methodology and getting initial provisioning to happen in less that a day.  There's nothing that irritates a manager more than having to sit around and wait for the new person's accounts to be created.  If we can get that time period down to a reasonable wait, hopefully to about the time it takes to fill out the remaining new hire paperwork, tour the facility, get the briefing from HR and have that welcoming cup of coffee, we will have made progress.

In the best of all possible worlds, provisioning should have already been started as soon as HR receives a signed offer letter.  Creating essential accounts in a a disabled state gets a lot of the heavy lifting done and front loads the whole process. This way all that has to be done is wait for the start date to occur and then enable accounts via a regularly scheduled work flow. However, I recognize that even creating disabled, locked accounts poses something of a risk so it will not be for all organizations. 

In the end careful analysis of current state, target state environments is called for along with a thorough examination of compliance, legal and best practices as they relate to the organization's needs.

SELECTing from the Identity Store

Now I don't know about you, but I've always had some issues with looking up entries in the NetWeaver Identity Management Identity Store. I know there are built in scripting functions like uIS_Get, uIS_GetValue, uIS_sGet, uIS_sGetValue, etc, but they've just never worked well for me. So to compensate, I've developed my own methodology for searching and retrieving items from the Identity Store.

The basic use case is this: The Identity Management solution needs to do a look up between an incoming data feed and the Identity store. The basic idea is that if the value from the feed and the value from the Identity Store match then the entries match and updating/provisioning can proceed as directed by workflow. I'm sure you can imagine other use cases, looking up managers, phone numbers, and other frequently used attributes.

The feed processing job will use a script to evaluate the match. Most likely it will pass MSKEYVALUE but could also use some other unique attribute in the feed.

The first thing that is needed is to determine the MSKEY, if any, for the entry to be worked with. To this end, I created the following query which will be implemented by NW IDM's uSelect function, which can be used in a Provisioning Job or Reconciliation task. Following best practices for NetWeaver Identity Manager, I am using the JAVA engine and therefore JavaScript in this example.

//Create an uppercase version of Par for checking against the SEARCHVALUE
uPar = Par.toUpperCase();

MSKEYQuery = "select mskey from mxiv_sentries where (searchvalue = '" + uPar + "')";
MSKEYResult = UserFunc.uSelect(MSKEYQuery);

You'll notice one of the first things we need to do is make sure we access the searchvalue correctly. Elements in this column always have their text elements stored in Uppercase, so we need to make sure that for the purposes of searching, we have an uppercase value handy. The results of this query are stored in a variable called MSKEYResult. Now that this information is available, we can now search for needed values related to this entry.

EmployeeNumQuery = "select avalue from mxiv_sentries where (mskey=" + MSKEYResult + ") and (AttrName='HR_EMPNUM)";
EmployeeNumResult = UserFunc.uSelect(EmployeeNumQuery );

With this query I can now look for a specific attribute value for a specific user and store it in a variable. At this point we should plan on returning a more nicely formatted version of the attribute so we will return aValue rather than SearchValue which is the value for the attribute as it entered into and subsequently processed by NW IDM for use in screen output, reports, emails, etc. In this example we are returning the user's Employee number.

This process might also include another query to do a count of returned Employee Numbers to protect against potential "dirty data" entries (multiple identities for the user or to many users with the same name.) If this scenario occurs more detailed searching, involving more attributes might be needed.

Note: I don't necessarily claim that this is the best or most efficient methodology for accessing this information. All I know is that it works for me and the way that I think / process information. If anyone has ideas on making this better or properly using the embedded functions listed above, I'd love to hear about it.

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.

Provisioning Concepts

Something that always comes up when working out new provisioning solutions is the problem of how to deliver account information to new users. Some solutions I've seen revolve around:

• Sending logon information to the users manager or sponsor
• Calling the user down to IT or IS to deliver the information
• Setting up the user with default credentials.

In all of these cases there's the risk of having other people besides the "provisionee" who have access to login information. This also does not scale when large number of users need to be provisioned as happens in Higher Education or when bringing new systems into the enterprise.

Now this can all be made slightly more secure by requiring the user to change their password when they login for the first time.

A popular way to handle this is through the use of what is called Account Claiming or Account Activation. In this process, login information is delivered to the "provisionee" either by email or postal mail with their login ID and a temporary password. The user is directed to a specific URL where they will be asked to enter their login ID and temporary password. After this information is loaded workflows can then be executed that require the user to amongst other things:

• Enter additional required information
• Set security information such as challenge/response questions
• Confirm existing identity data
• Perform other organizational/institutional tasks as required

This can be further secured by requiring that part of the temporary password be something only the user will know, such as elements of SSN, Birthdate, graduation year, etc. This helps us to fall into the old security formula of something you know + something you have = maxium security. I think that the ultimate levels of security will occur when the something you have is biometic in nature, but that is a discussion for another time.