We think, therefore I/AM:
The Case for separating Identity from Access Management
Just because an industry coins a phrase, it does not follow that the assumptions behind that phrase remain valid over time, or ever were valid to begin with.
Case in point: Identity & Access Management.
The Wikipedia entry for Identity Management even states that Identity Management (IdM) and Identity & Access Management (IAM) can be used interchangeably. This is unfortunate.
What’s the problem? Two functional concepts, Identity Management and Access Management, have been smushed together to form a handy acronym, IAM. While this may seem logical to some, largely out of habit, the smushing has historical and not logical origins. It’s a bit like the ATF, the US Bureau of Alcohol, Tobacco and Firearms, which got its strange mandate (and name) from a series of largely unrelated government policies defined over a 60-year period.
The beauty of software engineering, compared to other professions, is that it is less tied down by history: if a new way of doing things emerges, and a sufficient number of engineers are convinced the new way is better, it can quickly replace the old way. We face issues like backward compatibility, end-user adoption, and learning curves, to be sure, but our decisions are rarely guided by a respect for tradition. The emergence of cloud computing, DevOps and microservices are recent examples of this willingness to make sweeping changes in our methods to gain new advantages.
When NIST Researchers David Ferraiolo and Rick Kuhn formalized Role-Based Access Control (RBAC) in the early 1990s, the “problem space” was strictly human-facing: RBAC was initially described as an evolutionary improvement over Discretionary (DAC) and Mandatory (MAC) access-control approaches in use at the time.
We have upgraded our tech, but we have fallen behind in upgrading our methodologies & architectures to match.
Attribute-Based Access Control (ABAC), formalized as a generalization of RBAC, is an incremental improvement: Roles have been replaced with more expressive boolean conditions or Business Rules. But our model of the entity to whom privileges are granted has not been upgraded. In many real-world cases, that entity is not a human being, but a (physical or virtual) device, resource or running software or process. And while Business Rules are often an improvement on earlier approaches, they no longer represent the state of the art.
Rethinking Identity for the Cloud
The digital lifestyle — at home, at work, in transit — is transforming our very definition of identity. Leaving the existential and philosophical aspects of this transformation for another post, here are some of the practical & technical consequences of our new forms of identity:
- Multiple representations. A great number of people have two online identities: work and personal. A few have many more — one for each social network, for instance.
- Bruce Wayne / Botman. Many machine tasks run in the cloud on behalf of a (human) user. Automation services like IFTTT and Zapier rely on cached authorizations so their scripts can interact with online services at the user’s behest, essentially impersonating that user. Cloud infrastructure (Google Cloud, AWS, Azure) rely on “service accounts” to address that same issue.
- Heterogeneous IT landscape. Businesses used to make strong strategic commitments to a small number of IT vendors, or even a single ecosystem. Into the first few years of this century, we would describe this company as being “a Microsoft Shop,” another as being “Mac based” or yet another “run on SAP.” The rapid rise of Software as a Service (SaaS) and cloud-based solutions has brought greater diversity to large and small organizations alike; and with it, a substantial increase in the challenge of reaching interoperability and overall coherence. Simple use cases that started with the question “Who is this user?” are no longer simple.
A Step Toward All-Purpose Access Management
If Software Engineers have no reason to care about tradition, they also have little interest in intellectual elegance — at least not as an end in itself. Elegance is preferred, but only if there’s a clear benefit. So separating Identity from Access Management needs to yield tangible benefits or it’s just an academic exercise.
Before enumerating some of the many benefits of this separation, it’s worth mentioning that it is already underway. A number of startups have established themselves squarely in the Identity Management space, with minimal to no support for Access Management, or with Access Management spun off as a separate (often optional) offering. Examples of such successful ventures include Auth0, Dashlane, Okta and OneLogin.
Once Access Management is available as a separate functional unit, dependent upon, but not hopelessly intertwingled with, digital identity, some great things can start to happen, to wit:
- Transversal Access Management across applications and platforms. We’re not there yet, but in the near future you’ll be able to express policies like “Geraldine can Edit Content” once, and have them applied across your CRM, Content Management system and other SaaS applications.
- Multi-Identity-Aware Access Control. We deserve systems that know it’s you whether you logged in via SAML, LDAP, Google or Facebook — but that support policies that grant different privileges based on how you proved that you’re you. The “Update my bio” privilege might be granted regardless of how you were authenticated, but perhaps the “Open Space Station Airlock” privilege would only be granted if you logged in via one of the more hardened methods.
- Multi-Entity Access Management. A single framework should support Access Management for entities of all kinds: humans, bots acting on behalf of humans, autonomous bots, servers (physical, virtual or containerized), apps/services running within these servers… in essence, treat delegated entities as just one more authentication mechanism. Such a framework could provide vertically-integrated management, from network firewalls all the way up to human role-based or attribute-based permissions management, without having to resort to awkward palliative measures such as API gateway-level access management, OAuth2 callback endpoints, or “service accounts.”
Access Management has a clear cost/benefit threshold. If the system gets too complex, either it will require dedicated resources with specialized skills to manage — pushing its operating cost toward and possibly past its value — or it will need to be simplified to a manageable point, a step that can also reduce the system’s overall value.
Any change that let us “refactor” Access Management to reduce or maintain operational complexity levels, even as the managed policies get more complex, is a good thing.
Separating Identity Management from Access Management, and implementing & deploying them as two distinct, modular (albeit interdependent) systems, is a big step in a desirable direction.
Originally published at www.hubrix.co on October 17, 2018.
