The Case for Centralized IAM

as inspired by Manual Garat of Booking.com

⁠There have been some significant changes in the field of identity and access management (IAM) recently. In this context, we think it’s super important to discuss Centralized IAM, and the benefits of implementing it in your organization. 

This article was inspired by an interview by DataBreachToday.com with
Manuel Garat - head of IAM at Booking.com Manuel’s role includes providing secure identity management, authentication, and authorization to approximately 20,000 users a year, and facing these challenges has highlighted the importance of Centralized IAM for him. 

A new reality for Identity and access management

Several major changes have occurred in the past few years, posing new challenges in the field of IAM - influencing identity management, authentication, and most critically authorization. 

The shift to cloud-based solutions has rendered us unable to rely on the service being hosted in our internal environment. Having our systems in the cloud makes them accessible to users which are external to our domain, and that requires us to validate every request done against those systems. This is not only a question of access (authentication) but also a question of what these users have access to (authorization). 

More recently the threat landscape for identity, authentication, and access management has been particularly challenging during the ongoing pandemic. The creation of a decentralized workforce working from anywhere in the world has made it far easier to impersonate a user in your domain - thus creating an even greater need to ensure that the systems which are open for external access (which is most cloud-native systems nowadays) are being used exclusively by people we trust. 

This new reality requires us to improve on existing identity verification practices and adopt new ones. 

So far, organizations have mostly relied on recognizing a user as an employee in order to grant them access to the organization and its resources. Having employees all over the world - some of whom have never set foot in the actual office, requires us to validate if they are who they say they are. In this way, identity validation suddenly becomes super relevant. 

Additionally, we require more flexible, multi-factor authentication and more mature authentication models. We are forced to create in-depth criteria for access - a lot more complex than just allowing certain users access, and that process needs to be automated. 

There are two main options when creating access management - 

• Deciding you have a set of good practices and delegating them to individual systems.
• Controlling access management centrally, and offering it as a service to every system that needs to check whether a user can or cannot access its resources.

When considering these two options, you might think: “We don’t need centralized access management - as the owners of the application and its resources we perfectly know who should get access”.

Here’s our take - you definitely do know who should get access, but you don't always know who shouldn't have access. That’s not something we can always be aware of - thus creating a need for it to be instead controlled centrally. 

Just think of all the attributes we can have for both users and the services - country, department, billing status, usage quotas, errors, there are extensive criteria by which we might decide to allow or decline access. 

Having your access management centralized allows you to centrally enforce segregation of duties, restrictions, and strategic restrictions all in one place - and be done with it. Otherwise, you need to make sure all other different systems (Which there could be hundreds of), and their microservices (Which can bring us to the thousands) are implementing those restrictions at the right time and in the right manner. 

Another significant benefit of implementing a centralized authorization model is the fact that it allows validating the authorization models of applications. It is very typical to find applications that use overly broad permissions - which basically means users get a bit more access than they require. By centralizing the access management process you can validate those access control models, resulting in users having access to only what is necessary for them. 

The challenges of implementing a centralized model

Implementing a centralized model of authorization is complex. Mostly because your customers are not going to be homogenous, so you will have to be very flexible in terms of integration. But there is an even larger challenge here in creating acceptance for this adoption from your technical audience. The value of moving to a centralized authorization model is not always easily perceived, so there is a lot of palletizing that you need to do in explaining the ‘why?’.

At the end of the day this is a critical aspect of any product - and unless we provide good user experiences for it - users won’t adopt it. It’s not just about building, it’s about building it right.

The good news is - Centralized IAM is also available as a service, which allows you to bake in permissions and access-control into any product, create a separate microservice for authorization, and provide controls and interfaces to various stakeholders and customers. 

Modern Authorization

Modern systems which are highly composed of software are changing at high speed. The only hope of our controls, checks and balances to keep up is to be code-based themselves. One of the most important and recently popular practices in building cloud-native permissions is decoupling of policy and code. 

Decoupling Policy and Code

Having the code of the authorization layer mixed in with the application code itself can be very problematic. Most importantly, it creates a situation where we struggle to upgrade, add capabilities and monitor the code overall as it is replicated between different microservices. Each change would require us to refactor large areas of code that only drift further from one another as these microservices develop. This can be avoided by decoupling our policy from our code by (ideally) creating a separate authorization microservice that will be used by the other services in order to fulfill their authorization needs. Open-source policy/permissions engines such as Open Policy Agent (OPA) or SpiceDB for example allow us to manage authorization in a separate service. 

To sum things up

The changes in the field of identity and access management require us to rethink our approach when it comes to centralizing it and implementing it in our organization. 

The main benefits of having centralized IAM are:

• Allowing us to apply access in one place, enforcing everything across your different systems in an organized manner - including segregation of duties, restrictions, and strategic restrictions.
• It gives us an opportunity and the visibility to review and rethink the validity of the authorization models of our applications.

In the words of Manuel - “If you have your access management centralized, you can apply it once one in one place and be done with it”. 

See an in-depth interview with Manuel Garat, head of IAM at Booking.com
on this topic here.