The Security Trade-Off of Microservices
Among the many promised benefits of migrating from monolithic applications to microservices — scalability, independent deployability, and team autonomy — one challenge is often underestimated:
Securing many decoupled services is significantly harder than securing a single application.
Enterprise environments are already complex. Internal governance policies, client requirements, regulatory compliance, and security standards impose strict constraints on system design. When such constraints meet distributed architectures, complexity increases rapidly.
To cope with these demands, organizations frequently develop customized security solutions — including self-designed authorization protocols and, in some cases, even self-built authentication mechanisms.
Custom solutions may solve immediate problems, but they often slow down long-term change and innovation.
Authentication vs. Authorization — Still Confused in Practice
Two of the most fundamental concepts in IT security are authentication and authorization.
Authentication verifies a principal’s asserted identity or attributes.
Authorization determines whether an authenticated subject may perform a specific action on a resource under defined policies and contextual constraints.
These concepts are distinct — yet tightly coupled.
Authentication answers:
Who are you?
Authorization answers:
Given who you are, what are you allowed to do?
The coupling between authentication and authorization lies in trust.
Authorization decisions are made based on attributes — identity, roles, permissions, contextual properties. But those attributes must be trustworthy. Authentication provides that trust foundation.
If authorization were performed on unauthenticated or unverifiable claims, a subject could simply assert arbitrary roles or privileges. In such a system, policy evaluation would become meaningless, because the inputs to the decision process would not be reliable.
In other words:
Authentication establishes confidence in who (or what) is making the request.
Authorization evaluates what that authenticated principal may do.
Authorization without authentication reduces policy enforcement to accepting self-declared privileges.
Despite this conceptual clarity, many systems blur the boundaries in implementation.
The Common Anti-Pattern: Security Logic Inside Services
In practice, services often implement both authentication and authorization directly in application code. For example:
Verifying identity tokens in middleware or even inside MVC controllers
Performing hardcoded role checks inside business logic
Even when organizations rely on external IAM providers — which is generally advisable — services frequently:
- Enforce authentication at the application layer
- Depend on vendor-specific authorization protocols
- Embed policy decisions directly into service logic
This creates tight coupling between business logic and security enforcement.
The Orchestration Problem
The deeper issue is not merely token validation or role checks.
It is the lack of a clear strategy for:
- Orchestrating security across services
- Distributing and enforcing business policies consistently
- Managing identity propagation between services
- Supporting region- or regulation-dependent policies
In microservice environments, different teams often develop services with different IAM expectations. The result is a heterogeneous security landscape where policies are interpreted and enforced differently across the system.
When company-wide governance policies enter the picture — for example, IT or security department mandates — complexity increases further. Services must not only enforce project-specific rules but also comply with overarching business policies.
“But Monoliths Have These Problems Too”
Yes — many of these issues also exist in monolithic architectures.
However, microservices amplify them.
Distributed systems introduce additional concerns:
- Inter-service trust relationships
- Identity propagation across boundaries
- Policy evaluation consistency
- Latency and availability of authorization decisions
- Cross-region or multi-tenant policy variations
In a monolith, security flaws tend to be centralized.
In microservices, they become distributed and harder to reason about.
The Case Study
Considering the case study introduced in Chapter 0, we start with the following architecture:
The core components are:
- InnoDocApp – the document portal used by external partners
- InnoDocStore – the storage system containing internal documents
- DB-Metadata – a metadata database storing document attributes relevant for access control
Ideally, document content and access-control metadata are stored separately. By isolating authorization-relevant attributes from the document storage itself, operational responsibilities remain cleanly divided: IT operations manage document storage, while InnoDocApp manages access-related metadata.
This separation, however, introduces new concerns — such as synchronization between documents and their metadata — which we will leave aside for now.
What Happens in this Architecture
In this initial model, when a request for a document arrives, InnoDocApp must:
- Ensure the subject is authenticated
- Determine whether the subject is authorized to access the document
- Compare subject attributes (roles, claims, etc.)
- Evaluate them against document attributes stored in DB-Metadata
- Execute the corresponding database operations (download, read, etc.)
The critical issue:
Steps 1 and 2 are embedded directly into the application.
This tightly couples security logic with business logic — exactly the pattern we want to avoid.
Externalizing Authorization: The PXP Architecture
The OASIS work group introduced a standardized approach to externalize authorization decisions. Within the OASIS ecosystem — particularly in the context of XACML — this architectural pattern is known as the PXP architecture.
The PXP model separates authorization into clearly defined components:
1. Policy Enforcement Point (PEP)
An access request is received by the PEP.
The PEP:
- Intercepts the request
- Enforces the final decision
- Does not make authorization decisions itself
Instead, it delegates the decision to the PDP.
2. Policy Decision Point (PDP)
The PDP evaluates whether a:
- Subject
- May perform an Action
- On a Resource
It returns a decision such as Allow or Deny.
The PDP contains no business logic — only policy evaluation logic.
3. Policy Administration Point (PAP)
The PAP defines and manages the policies that govern access control.
It answers:
What are the rules?
4. Policy Information Point (PIP)
The PIP provides additional attributes required for decision-making:
- Subject attributes (roles, department, clearance level)
- Resource attributes (classification, ownership)
- Contextual information (time, region, risk signals)
Without the PIP, the PDP would lack the data required to make informed decisions.
Why This Matters
The PXP architecture formalizes what we conceptually want:
- Applications should not decide authorization.
- Policies should not live in business code.
- Decision logic should be centralized and replaceable.
- Attribute retrieval should be separated from policy evaluation.
Instead of embedding authentication and authorization directly into InnoDocApp, we externalize policy evaluation and turn the application into a pure business component.
This architectural separation allows authorization to:
- Scale independently
- Be audited centrally
- Be updated without redeploying services
- Be standardized across teams
And this is exactly what our InnoDocApp scenario requires.
In the next chapter, we will apply the PXP model concretely to our case study and show how InnoDocApp can delegate authorization decisions entirely.
Top comments (0)