| By Matthew Pollicove |
Article Rating: |
|
| September 18, 2009 03:51 PM EDT |
Reads: |
129 |
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:
- IAM is just another system for IdM to manage. This makes sense when considering considering the relationship between NW IdM and GRC.
- 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.
- 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)
Ulitzer content is offered under Creative Commons "Attribution Non-Commercial No Derivatives" License.
For any reuse or distribution, you must make clear to others the license terms of this work.
The best way to do this is with a link to this web page.
Any of the above conditions can be waived if you get written permission from Ulitzer, Inc., the copyright holder.
Nothing in this license impairs or restricts the author's moral rights.