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!

IdM vs IAM

I've actually been thinking about this for a while after several conversations and then reading a blog entry by Earl Perkins of Gartner, Which made me realize that it is time to bring this discussion into the open.

All too often IdM (Identity Management) and IAM are used interchangeably and this a not a good thing. Let's break it all down:

Identity Management had to do with the creation, maintenance and eventual retiring of enterprise accounts. Many people, myself included have discussed this concept in blog entries, presentations, white papers and other forms of media. Sometimes, but not always, workflow mechanisms might be used to handle processes in a specific order or allow for approvals by specific person or persons.

IAM (Identity and Access Management) is about the extra use of controls for Web or Physical Access Management. From the Gartner article this seems to be more about configuring a user in a multi-factor authentication, a firewall device or SSO app rather than setting Active Directory's userAccountControl attribute. It may or may not deal with provisioning to enterprise systems as mentioned above in IdM, but it will provide for population of the Access Management system.

So what can we conclude from this. I've come up with three basic scenarios:

1. IAM is just another system for IdM to manage. This makes sense when considering considering the relationship between NW IdM and GRC.
2. IAM is a super-set of IdM - I think this is how we should consider projects where the IdM system is tasked with heavy role and group management which then ties into the Access Management Tools.
3. IAM is a completely separate discipline with separate systems. This could be the case when there is extreme segregation of the provisioning and security infrastructures.

I don't think that there is any problem with any of these scenarios, after all, according to Pollicove's Law of Provisioning, every implementation will have it's own unique architecture that needs to be satisfied. I don't even think that there's much of a difference between the first two scenarios from an operational context. Rather, the real difference is going to be architectural and based on working with your customers. 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, but that is a thought for another day. (coming soon)

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.

(Database - Sun) + Oracle = Acquisition

It seems that the Europeans are putting their two cents into the pending acquisition of Sun by Oracle.

Can't say I'm surprised as many businesses in Europe and around the world use MySQL. I've often thought that this more than anything else would get in the way of the acquisition. Of all the areas of overlap, this seems to be the one that matters the most.

Oracle already owns one of the biggest databases around, now it stands to acquire another one with world wide appeal. As the article quoted above mentions:

Regulators must “examine very carefully the effects on competition in Europe when the world’s leading proprietary database company proposes to take over the world’s leading open-source database company,”

It's also a key part of the SAP system (in the form of MaxDB), which I am sure is part of the European investigation whether it is specifically mentioned or not, as the article also states:

“the enquiry will focus on the extent to which open-source software developers would be able to continue to develop software based on the open-source MySQL database,” which Sun bought last year and which is widely used.

I'm still thinking that the simplest solution to to sell MySQL to SAP. It would create a level playing field between Microsoft, Oracle/Sun and SAP.

All would have ERP and database tools. Microsoft and Oracle/Sun would still have operating systems, but I don't think this is a big issue for SAP since they not only run just fine on both. Additionally I think we all realize that SAP drives purchases of operating systems and tools from the other companies.

Can't wait to see what happens...