Building a real-world IAM system: centralized vs. distributed

Raise your hand if you’ve ever been locked out of your banking app, a hotel room, your work computer, your car, your Gmail… the list goes on. You know the reason your access was blocked was because you either forgot your keys/password or had the incorrect login credentials. 

Businesses of every kind implement identity and access management (IAM) systems for your protection, and their own. Failure to protect humans and resources can easily result in devastating consequences. 

In this post, we will examine several challenges associated with building an IAM solution, and two different approaches to architecting these systems. 

Challenges with building an IAM solution 

A key component of building an IAM system is about acknowledging that breaches and downtime can, and likely will, happen. Our recent State of Resilience report found that 100% of participants reported an outage within the past year and that 89% associated downtime with customer loss. 

Organizations want to do everything possible to mitigate downtime, outages, and security threats. Whenever users or systems can’t get access to the right information, or their information is compromised, there is a direct hit to the company's bottom line. However, architecting a resilient system can be challenging, especially if you are using a legacy solution with an active-passive setup. 

Another challenge is making sure your architecture can scale as you acquire more users and connect more systems. An increase in your user base (or assets requiring access control) can create strain on systems because of the need to scale. The database often becomes a performance bottleneck if it has limitations around scale, or requires you to manually scale.  

Scaling can become even more complicated when you need to service new geographies and meet compliance requirements within those new regions. Which brings us to another challenge: how will you adhere to all of the various data privacy regulations? Audits will certainly happen and you need to be transparent about how you are managing your data. 

Finally, inconsistent data can be detrimental. When updates are made to your system, or permissions or changed, can you be confident that those changes are accurate across systems? What about at scale? What type of transactional guarantees do you have in place? 

There are different types of IAM architectures with various strengths and weaknesses. Ultimately it's up to the business to choose which approach is the best fit for their use case. 

Solution #1: Centralized IAM System

The most common type of system is a centralized IAM architecture. In this scenario, all identity and access management functions are centralized in a single location or region. 

This approach is typically easier to manage and secure. You can streamline identity management and simplify user access with a single set of credentials. You can also deliver a consistent user experience across all applications since data correctness is usually guaranteed. Because all of this is happening within a single location, it's easier to secure and manage. 

In the diagram below, you can see that users and/or devices will perform various actions that need to be identified, authenticated, and/or authorized. There’s also protected assets that require controlled access and security through IAM policies. And at the heart of these systems is the database. 

As your organization grows, so does the complexity of managing your IAM system. Since the database is a central component, it can become a bottleneck (and even cause downtime) if there are a lot of users and resources constantly hitting the database. In this case you will need to scale out, however, legacy relational database systems (RDBMS) that require manual sharding add even more complexity and operational overhead.

Additionally, if you are using a traditional RDBMS, then you are likely leveraging an active-passive setup. With this setup, you are at risk for downtime and losing data during failover. You could implement an active-active configuration instead, but this model often presents consistency issues since multiple replicas might be trying to edit data at the same time. 

If your organization is a small or medium-sized business that’s located in a particular geography, with no plans to scale further, and can compromise high availability for simplicity – a centralized IAM system might work well for you. However, if you have users spread across the globe, or aspire to, you might want to consider another approach: a distributed IAM system. 

Solution #2: Distributed IAM System

A distributed IAM system is a more modern approach that refers to a system where identity and access management functions are distributed across multiple regions or locations. Note that this is different from a decentralized IAM system where there’s no central entity and all nodes have equal authority – meaning control of the system is significantly dispersed. In distributed IAM, you can still have a central entity overseeing all systems. 

In the diagram below, you will see a zoomed out version of the one above, that’s running across three different regions. The actions hit the database that’s closest to their physical location. Even though there’s nodes spread out across three regions, the database (in this case CockroachDB) still functions as a single logical system. 

This approach is more scalable than a centralized architecture since the database is distributed and horizontally scalable – you can simply add nodes when you need more volume or throughput. Additionally, since users are hitting the database in the regions closest to them, it reduces latency. If you are required to keep data in a particular region for compliance, you can pin data to a location.

When you run your application across multiple regions using a distributed database, it increases the likelihood of surviving failures. If an entire region goes down, data is redistributed to the available regions. A database like CockroachDB also has a multi-active architecture which means the database has at least three active nodes, each of which can perform reads and writes for any data in the cluster without generating conflicts. And, multi-active databases only accept writes when it can guarantee that the data can later be read in a way that’s consistent.

All that being said, distributed IAM can be more complex to manage and secure. This is where the database plays an important role: you must have a solid foundation for your IAM data for this architecture to work. Ideally it should be a database that’s purpose built for distributed transactions and consistency, with enterprise-grade security. 

Summary

IAM systems are used online and in the physical world, and in almost every case, these systems are considered mission-critical. The right foundation for an IAM solution allows you to empower employees while protecting your data across your organization. While there are many challenges associated with building an IAM solution, there are tools and methods that can help based on your specific needs. 

If you want a peace of mind that your system is built on the best foundation possible, get in touch to see how CockroachDB can help. 

Special thanks to Shannon Dew, Principal Sales Engineer at Cockroach Labs, for providing content for this post.