In the information security industry, the IAM acronym is well known, it's the acronym for Identity and Access Management. IAM is used in blogs and tweets, consultants manage IAM projects and vendors sell IAM tools and suites. But I am feeling less and less at home with this acronym: it feels like a false acronym.
Identity Management (IDM) and Access Management do not exist together. These terms point to different processes and responsibilities. Let me explore and explain this some more.
Identity Management is a process for managing the lifecycle of identities within a trusted domain, be it a real or virtual organisation or an Internet resource like a mailserver. Identity Management is responsible for managing digital identities and user accounts. It is about 'who', it's a process for managing 'subjects'.
Access Control is a whole different ballgame. It's got nothing to do with 'who'. It's all about defining 'what' and 'why' for accessing 'objects'.
Access Control is about defining the access policy for managed objects and resources. And it's about the person responsible for defining these policies. Access Control is a shared responsibility for a process owner, who in turn should define access rules for realising Seggregation of Duties, and a Data Owner, who is responsible for data governance and who should define access rules based on all kinds of laws and regulations.
The process owner and the data owner have to decide what kind of permissions should be available under what conditions. A process owner should not be interested in managing the accounts accessing his resources, but he should be interested in why accounts might be able to access his resources. And he must be interested in the audit trail: who did what.
Of course there is a link between the two processes. And that's simple because Who can do What and because of Why. The link is the digital identity, in most cases addressed as a Role of User Group.
Identity Management can largely be supported by tools. IDM is responsible for synchronising user accounts, roles/groups and passwords between systems and for provisioning attributes towards all kinds of related systems. The business case for IDM is in lowering costs. A single point of administration lowers operational costs and results in better data quality because of it. IDM can be implemented in an IT project.
Access Control is a business process. There's not a lot of technique in this process. Of course the rules have to be implemented in systems, but it's not an IT responsibility. The business case is not in lowering operational costs, but in delivering better transparancy and governance.
IAM projects tend to result in either an IDM implementation or in nothing at all. So why call it IAM after all? We better start calling it Identity Management and Access Control, or, as I tend to do, IDM/AC.
With the growing acceptance of Identity Management services in the cloud, separating IDM from AC is a logical consequence. The next step will probably be delivering Access Control in the cloud, in the form of Policy decision engines using SAML and XACML. And this process is better of by not managing Identities at the same time, so that it can be re-used regardles of the process that requires this kind of functionality.
