IAM = Identity Access Management
Some forward thinking people in the industry have worked on IAM for well more than a decade. Some people equate IAM with the security problems of authentication and authorization. Others equate it with Single Sign On (SSO). In the context of the Internet, IAM is inextricably linked to certificates, signatures, and secure communications. Under the flag of “IAM”, I plan to sort out and refresh years of my notes on these topics.
The way IAM seems to be evolving is for the identity and the access rights of some entity to be encoded in a “token”. If the entity A can securely pass its identity token to entity B, then B knows who (or what) A is. Now A may have some access rights to something controlled by an entity C. If these access rights can be encoded in a second token, and A can securely pass the identity and access tokens to C, then C should be willing to give A access. The study of IAM is to make precise sense out of these hand waving thoughts. What is the structure of the tokens? Who and how can create them for an entity? How exactly are they securely passed around? What deep issues are there? What standards are there?
There is more to IAM than just tokens. My biggest worry about making authentication and authorization work on the Internet, which to me is way more scary than on a private LAN, is that the complexity of the IAM system could well introduce more security problems than it solves. What is clear is that the security of an enterprise is under attack by some pretty sophisticated “bad guys” with their Advanced Persistent Threats. Lots of credit cards and social security numbers are being stolen. This is already a nightmare. How bad does it get when IAM is in place? What does the bad guy who has penetrated an enterprise have access to now? It is clear to me that long, complicated passwords being used as authentication to an IAM system are easily stolen. Thus two (or more) factor authentication is an essential requirement for IAM, but I’m getting ahead of my posts.
Another issue that IAM is addressing is the huge variety of “use cases”. The early use cases for IAM involved large enterprises using traditional servers and workstations. Good examples involve supply chains involving many companies. Now it is clear that mobile devices will be the primary player in IAM. For example, how does one secure a banking transaction initiated with a wrist watch? A heavy-duty protocol probably won’t work. The entire “Internet of Things” has IAM ramifications that the industry hasn’t really addressed, and its use cases seem endless here.
My notes on IAM start with a quick review of JSON here. By clicking on the IAM archive link in the right-hand panel, you can get all the IAM notes, but unfortunately they are listed in reverse chronological order. I put a link in each note to the next one so that you can read them in a more logical order.