IAM glue

In a decentralized, decoupled, distributed world, where each (micro) service fends for itself and modules are pieced together to deliver leaner, laser-focused functionality, there is an ever greater need for a “glue” to hold everything together. What can we expect? That everything would magically stick together?

Identity & Access Management (IAM) is that glue. It brings you two things: a coherent, consistent Identity used across all services in a systematic way. You are who you are no matter what you are consuming. That has extended beyond the traditional realm of the enterprise and entered the consumer world. Behold CIAM: consumer IAM. This is one part of the glue.

The other part is Access Control. Determining, authorizing, and knowing who can do what and under which circumstances. In the past, each silo or monolith would decide on its own what users can or cannot do. This would be achieved through code, or roles and permissions.; requiring time-intensive configuration, role engineering, access review, and never-ending maintenance. And let’s not forget mountains of spaghetti code that would be tacked onto the applications to make sure only the relevant users would access the relevant functionality. A sticky mess. This is where Externalized Authorization kicks in. It sits outside of each microservice, application, or system; it’s managed centrally; it’s policy based.

In the customer implementations I have been driving lately, a common architecture and usage pattern has emerged. Customers implement an API-first strategy – sometimes as extensive as a microservices architecture. They rely on an external IAM provider for identity management and authentication. They occasionally make use of OAuth 2.0 and OIDC for authentication and delegated access.

And they see increasing value in the use of Axiomatics to deliver policy-based, externalized authorization. The goal is to design a set of policies which addresses the authorization needs of all the APIs and underlying infrastructure in a consistent fashion.

The fact that it is policy-based means that:

  1. The requirements can be more easily mapped into the technical configuration i.e. the policies.
  2. The latter can be easily audited to prove the overall system’s compliance with the requirements.

Furthermore, the policies are not set in stone. Policies can easily grow to cater to new scenarios and regulations without having to go through a hefty overhaul process. This makes your entire IT more agile and faster to respond to evolving business requirements.

If you’ve heard the “digital transformation” catch phrase, you know full well how important it is to be proactive. Externalized Authorization helps you be proactive. Because policies can be reused across layers (from presentation to SSO to API to data and beyond) and across business units (finance, HR, core business…), they become the glue that ties the different pieces together. They bridge the gap between IT and business. So, as you jump into this brave new world of decentralized IT, rest assured, we’ll be there to make the right authorization decisions for you.


Looking for more information on externalized authorization? Check out our recorded webinar: Externalized Dynamic Authorization in a [Micro]Services World.


Leave a Reply

Your email address will not be published. Required fields are marked *