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)