Since I’m observing the IAM business, it has been under constant change. However, there is a change on its way that is bigger than many of the innovations we have seen over the past decade. It is IAM adopting the architectural concept of microservices.

This will have a massive impact on the way we can do IAM, and it will impact the type of offerings in the market. In a nutshell: microservices can make IAM far more agile and flexible. But let’s start with the Wikipedia definition of Microservices:

Microservices is a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight. [Source: Wikipedia]

Basically, it is about moving to loosely coupled services and lightweight protocols for integration. Factually, this also includes lightweight APIs these services expose. Each microservice delivers specific, defined capabilities, which are then orchestrated.


When we look at the evolution of the IAM market, most applications have been architected more or less monolithic in the past. Most of them have some “macroservice” model built-in, with a couple of rather large functional components such as a workflow engine or an integration layer. Some vendors already have come a bit further in their journey towards microservices, but when looking at today’s on-premises solutions for IAM, for most vendors the journey towards microservices has just started, if at all.

Looking at IDaaS (Identity as a Service), the situation is different. Many (but not all) of the IDaaS solutions on the market have been architected from scratch following the microservices approach. However, in most cases, they do so internally, while still being exposed as a monolithic service to the customer.

The emerging trend – and, even more important, the growing demand of customers – now is for IAM being delivered as a set of microservices and via containers (which might contain multiple microservices or even a few legacy components not yet updated to the new model). Such an approach allows for more flexible deployments, customization, integration, and delivers the agility businesses are asking for today.

From a deployment point of view, such architecture gives business the option to decide where to run which of the services and, for example, support a hybrid deployment or a gradual shift from on-premises to private cloud and on to public cloud.

From a customization and integration perspective, orchestrating services via APIs with IAM services and other services such as IT Service Management is more straightforward than coding, and more flexible than just relying on customization. Lightweight APIs and standard protocols help.

Finally, a microservice-style IAM solution (and the containers its microservices reside in) can be deployed in a far more agile manner by adding services and orchestrations, instead of the “big bang” style rollout of rather complex toolsets we know today.

But as always, this comes at a price. Securing the microservices and their communication, particularly in hybrid environments, is an interesting challenge. Rolling out IAM in an agile approach, integrated with other services, requires strong skills in both IT and security architecture, as well as a new set of tools and automation capabilities. Mixing services of different vendors requires well-thought-out architectural approaches. But it is feasible.

Moving to a microservices approach for IAM provides a huge potential for both the customers and the vendors. For customers, it delivers flexibility and agility. They also can integrate services provided by different vendors in a much better way and they can align their IAM infrastructure with an IT service model much more efficiently.

For vendors, it allows supporting hybrid infrastructures with a single offering, instead of developing or maintaining both an on-premises product and an IDaaS offering. But it also raises many questions, starting with the one on the future licensing or subscription models for microservices – particularly if customers only want some, not all services.

There is little doubt that the shift to microservices architectures in IAM will significantly affect the style of IAM offerings provided by vendors, as it will affect the way IAM projects are done.

See also