Managing the digital keys to the kingdom: how to achieve control over your IAM data

For many organizations, identity access management (IAM) systems are like the digital keys to the kingdom and the foundation for their day-to-day operations. Building and maintaining an IAM system can be extremely complex if you aren’t using the right infrastructure to support your business needs. 

In a previous post, we examined why IAM is critical to businesses, the challenges associated with building an IAM system, and compared a centralized vs. distributed system. Here we will discuss how you can achieve granular control over your IAM data in a distributed environment. 

Control requirements for IAM systems

IAM systems are constantly handling logins, permissions, authentication – all which generate a relentless stream of transactions. When you have a global business, you may use a distributed IAM system where identity and access management functions are distributed across multiple regions or locations. 

A distributed approach helps increase the resilience of the system, enables horizontal scale, and can reduce latency for the end user if they are accessing data in the region closest to them. So if you choose to deploy your IAM system across multiple geographies, what does the database implementation look like? 

Below is an entity-relationship (ER) diagram outlining the core components of a generic IAM system. If you are a database administrator and/or architect, you know that these diagrams are typically used to plan and debug relational databases, and to help define the schema which creates the physical database. 

Now, the critical thing to remember is that within an IAM system, not all data is created equal. Different tables have vastly different requirements depending on their content and context, how it's accessed, and various performance needs. 

In this example, the admin tables might need to have lightning fast interactions to allow for immediate access. However, the token_usage_histories table might not need as quick of response times, but need to be physically stored in specific regions to comply with data regulations. 

When using a traditional relational database system (RDBMS), you have a certain level of control when it comes to creating, modifying, and deleting tables and data. However, you typically are not able to control the physical location of the table and data – let alone in a single, globally distributed database.

Achieve granular control over your system

Table locality settings are beneficial for a number of reasons. First, they help optimize latency for different read/write patterns so you can make sure you have fast access for tables that require it. Second, they allow you to pin data to a particular region so that it never leaves, which helps with regulatory restrictions. 

With a distributed database like CockroachDB, you can control data locality at the table level, ensuring granular control to fit your application requirements. Data can be read or written across all regions of your cluster, but tuned to meet the challenges you face at a table level. In fact, you can alter the locality of your data as your requirements evolve, without taking the database or table offline. 

Using the admin example above, your administrators are likely located in a single region, so their interactions with the admin configuration data need to be instant. This is the perfect place to use CockroachDB’s Regional Tables to ensure the read/write latency is lower in that particular region.

Now what about addressing the complexity of data regulations? For example, with the token_usage_histories table, you might need to store this data locally in specific regions to comply with GDPR. This is where geo partitioning with REGIONAL BY ROW comes into play, allowing you to control data residency at an extremely granular level within a table. You can physically partition data within the same table, based on a condition, such as region or country code like you might find in token_usage_histories.

What if you have data that needs fast read access across all regions in your database? For example, user information, role definitions, access policies – these are frequently read but less frequently updated. For a seamless user experience and low latency reads everywhere, you can use GLOBAL tables.

See how the diagram below has different rules for different tables. 

Traditional, monolithic databases struggle to accommodate this diversity of needs. They're simply not designed for the flexibility and nuance requirements in a modern, global IAM environment. Other modern databases may try to solve these challenges by creating read-only replicas in multiple regions, thus sending all writes through a primary or master region. This leads to compromises – either sacrificing latency in some regions or struggling to meet compliance requirements in others.

But with your IAM system, you shouldn’t have to make compromises. Instead, you can use CockroachDB’s distributed architecture plus features like granular table locality that will allow you to tailor your data storage to the specific needs of each table. You can achieve low latency where it matters most, ensure compliance with data residency rules, and deliver a seamless, high-performance IAM experience to your users, everywhere. 

Summary

As with many use cases, it’s about having the right tool for the job and CockroachDB is purpose built to tackle the complexities of IAM systems. 

If you want to learn more about managing the digital keys to the kingdom, 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.