Access Management and Micro-services – Part 1: Overview

An ongoing trend, as organisations increasingly adopt cloud-native development approaches, is from centralised services, to widely distributed services. This shift requires a rethink about how access management is delivered, in terms of aligning with this model in development practice, as well as accommodating the radical effect that this has on deployment architecture. I have previously alluded to this shift as being from ‘perimeter-based access management’ to ‘centralised access management’, and how this is able to accommodate the increasing adoption of distributed infrastructure and services.

I initially began writing a post which would explore this concept in more detail, though it quickly grew beyond what could be easily captured within a single post. As a result, in order to give the topic justice, I will break this into a number of posts, beginning, in this post, by exploring what Access Management even looks like in this sort of architecture, then going into more detail about strategies for implementing a micro-services approach to access management.

Posts in this series

• Part 1: Overview
• Part 2: Authentication and Authorisation
• Part 3: Advanced Authorisation and Assurance
• Part 4: Enabling Other Teams and Inter-Service Authentication

I will update this section with links as I publish the upcoming sections.

The role of Access Management in a Micro-services world

The concept of micro-services is to modularise services around business capabilities. As such, a core question that needs to be asked is ‘What are the core business capabilities of Access Management?’ This central question will drive what should, and perhaps more critically, should not, be included in any services provided by the team responsible for Access Management. My view is that this team is responsible for everything related to user identity. They are responsible for registering users, verifying a user’s identity (i.e Authentication), and most importantly in this architecture, providing other services with information about a user’s identity that they can use to make authorization decisions. It is this final point that I think is critical. In distributed micro-services architectures, the access management services should not be responsible for making authorisation decisions.

This is a fundamental change from a perimeter-based architecture that I think warrants further explanation, as traditionally both authentication and authorisation have been solidly within the remit of the access management components. Yet there are a number of reasons to break these apart, beginning with usage patterns. Authentication services are typically called once per session, while authorisation needs to be applied on every service invocation. In a perimeter based model, this was easy to achieve, as all calls went through the perimeter enforcement point, which performed authorisation, and redirected to authentication endpoints if required. Consider the following, which occurs when the approach is applied to a model with distributed services:

If you are passing through an authorisation enforcement point, then invoking a service, the distance between those points becomes a serious consideration. In a traditional model, where they were often in the same rack, or at least the same building, the latency was typically in the single-digit-milliseconds, but when I refer to ‘distributed services’, I imply that no assumptions can be made about relative locations. The latency could be <1ms between nodes in a rack, or it could be >300ms as it travels across the ocean.

As a result, in a distributed model, it simply doesn’t make sense to use a single point that implements both authentication and authorisation. It might be possible to take pains to tightly control your network topology, ensuring co-location or dedicated high-bandwidth low-latency links, etc. to mitigate some of the effect, but doing so reduces the ability to rapidly deploy and scale, requires a lot of coordination between small teams, and generally undermines the development approach.

Instead, in the alternate model, in which authorisation is performed by services themselves, the flow looks like this, completely eliminating the impact of relative service location:

Initial authentication is made against authentication services, then other services are invoked directly, performing their own authorisation, with no need to go through any common point.

Another practical reason for removing authorisation from the access management services has to do with the development model. A shift to micro-services is often able to accommodate a much more rapid development model, with short release cycles for services with narrow scopes. Requiring the team responsible for access management to be across every new service in order to develop an authorisation model risks adding considerable latency (both development time, and network) and is going to be impossible to implement at scale, as it spreads the access management team very thin.

Ultimately, I find that strongest argument for moving the responsibility for authorisation from the access management team to service developers is one of team specialisation. Where the access management team is focussed upon the identity of users, the team developing new services ought to be focussed around whatever it is that those new services actually do. Those developers are therefore in a much better position to understand which users should and should not be using their services, based upon the business requirements that they are developing towards (if the services are intended as internal services for other applications, then there is much less requirement for an authorisation model outside of governance requirements). As a result, those developers are in a much better position to design and implement whatever authorisation model is required, and the access management team is responsible for ensuring that the identity information required by this authorisation model is available.

With scope of the Access Management services established, in the following posts in this series I will explore in more detail the services and approaches required in order to facilitate this model. Initially we will focus upon looking at existing standards for performing authentication and authorisation, then shift to extending this with additional services which facilitate access to identity information, as well as enabling other service development teams to rapidly implement a consistent and appropriate approach to access management.