Recent conversation at education conference:
“… but why the name Identity Lifecycle Manager? It is just confusing!”
“What about the name is confusing?”
“The WHOLE thing! It was a stretch to call it Identity Integration Server!”
At this point I realized that the problem was not the name, but the customer's lack of understanding between the differences of an identity and a login ID. So I asked, “Do you have identities or login ID’s?”
“What’s the difference?”
A “login” is like your house key. It unlocks your front door or many doors in the house if locks are keyed the same, but does not give you any access to neighbour’s house. So in a network environment your login is your key to multiple systems within your network, but won’t give you access to systems controlled and owned by research partners or customers. What happens if you try your key in the lock of a system outside of your realm? Immediate rejection!
An “identity” is like your driver’s license. It is issued by a trusted entity, contains enough information to properly identify who you are, and grants you permission to drive within the realm of the issuer (Texas for me). In a network environment your identity will identify who is using a slice of data from a trusted 3rd party (a certificate or a Kerberos ticket for example) and usually grants you permissions to systems within the realm of the issuer.
There is also a big fundamental difference between your keys and license; the way authentication is done. A lock and key are based on the premise of having shared information to confirm identity. If the key does not match the tumblers properly then the lock will not turn; if the password hash of your password does not match what is in the account store then the “lock will not turn”. Authentication with an identity is trust based. Meaning, if your identity claim is validated by a trusted 3rd party then the system agrees that you are who you say you are (authenticated).
The diagram below is a good example:
1.) The client attempts to access a web server outside of her realm
2.) The web server requests authentication
3.) The client goes to her local federation server
4.) The federation server validates her account in the directory
5.) The federation server issues her a claim-based token to present to the Adatum federation server
6.) The Adatum federation server validates the token
She is now allowed access the web server (over simplified to some degree).
So why is ILM needed again? An identity should contain a certificate that can be presented to systems for authentication. If I give you my keys (username and password) then you can access my house! However, if I give you my identity all you can do is present it and it’s the decision of the resource to honor it and give you access or to reject you.
So ILM extends the reach of both your key and identity.
ILM will keep your key (username and password) consistent across many systems and ensure that all data related to your identity, from all the appropriate systems, is kept current. Plus a whole lot more …
