How “The Lord of the Rings” predicted modern IAM challenges

This is the second in a three-part series on identity-as-a-service, Zero Trust, and security-in-depth.  

In our last blog, we looked at modern identify and access management (IAM) and more specifically identity-as-a-service (IDaaS) solutions. These can securely authenticate users and verify that they are who they say they are. More importantly, these solutions verify that users are authorized to use the services or applications for which they’re requesting access. IAM and IDaaS can provide contextual security, account for outside factors, and even identify users who are compromised after they’re granted access.

So how does “The Lord of the Rings” fit into this at all? In Tolkien's masterwork, he envisioned a series of rings, with Rings of Power given to Men, Dwarves, and Elves, and One Ring, the Master Ring, forged to rule them all. Okta, Azure Active Directory (AAD), Google Suite — they can all be thought of as Rings of Power. AAD, for example, allows administrators to control users and access to Microsoft 365 but falls short of providing IAM outside of this tightly controlled environment.

In another way, the Great Rings could be thought of as the story of our devices — computers, smartphones, tablets, IoT devices. In the same way that we have multiple devices, we have multiple IDaaS solutions. Google Suite — one such directory service — is popular with organizations especially those leveraging Google apps. But, nearly all those organizations also leverage Microsoft 365 (Word, PowerPoint, Excel, Teams, etc.), and Azure Active Directory is the preferred directory service for those business users.

So IDaaS solutions are all looking to become the One Ring — the one master IDaaS that can provide identify services across ALL applications, workloads, users, and identities. Many IDaaS solutions will promise this, but the reality is somewhat different.

Okta has taken a bold approach in some ways. Okta's Risk Engine uses the on-premises user’s account credentials combined with cloud-based factors such as device health, location, and behavior patterns — all to build what’s often referred to as an Assurance Level. In that way, they can presuppose the risk related to granting access.

The problem of the Many Rings

While solutions like the risk engine can expand IDaaS to include contextual awareness, this still doesn’t address the problem of the Many Rings. Organizations have multiple directories, and each is often highly tailored to specific use cases, such as AAD. There is a lot more required.

The One Ring notion stands a single IDaaS in front of these other directories, and in theory, provides what the individual directories cannot — a single “proof point” for identity and access management. IDaaS solutions are expanding their vision to include APIs and management for other directories, but there are legitimate concerns around whether the IDaaS solutions will evolve as quickly as the directories they are supporting. If the IDaaS solutions cannot keep up, they can become blockers to innovation and early adoption of new technologies. This is known as ‘technology lock-in’ or ‘technological path dependence,’ and it can contribute to inefficiencies in business workflows.

Risk never goes away – in fact, it’s an arms race between organizations and attackers.   Therefore, standing more and more sophisticated authentication tools in between the user and the workloads might simply contribute to this escalation. This is where Zero Trust comes in. Zero Trust is a security model that helps unify IDaaS solutions without contributing to potential technology lock-in and other significant risks.

In our next blog, we’ll look at how Zero Trust plays with IDaaS, but in the meantime, check out Barracuda's CloudGen Access solution. It’s Zero Trust that plays nicely with IDaaS without adding unnecessary overhead and complexity.

This is the second in a three-part series on identity-as-a-service, Zero Trust, and security-in-depth.