Externalized Dynamic Authorization in a [Micro]Services World Pt. 3

Mark Berg   ·   Thursday, December 15th, 2016

Part 3: Microservices Authorization In-Depth

This is a multi-part series of articles describing why and how one can approach applying Externalized Dynamic Authorization to an API and/or microservices architecture that uses OAuth 2.0 flows and/or OpenID Connect (OIDC). Externalized Dynamic Authorization and OAuth 2.0 (and/or OIDC) are complementary technologies. Some of the naming can lead to confusion however, on what roles each can and should play. The series is divided into multiple parts: This Primer provides some background of the standards involved in this series, including OAuth 2.0 (referred to as just OAuth from here on out) and OpenID Connect (OIDC). The eXtensible Access Control Markup Language (XACML) tutorial is available as well.

• Part 1 of this series will show some patterns of how Externalized Dynamic Authorization could be integrated within an OAuth or OpenID Connect (OIDC) flow.
• Part 2 will contrast OAuth scope-based authorization with Externalized Dynamic Authorization.
• Part 3 will discuss how Externalized Dynamic Authorization itself can be a microservice and best practices for leveraging the authorization service within the microservice architecture and its principles.

This post will evaluate whether externalized dynamic authorization has a place within a microservices architecture. The Microservices Architecture and its principles were described in the primer. Let’s utilize the following example to provide context for our discussion about externalized dynamic authorization. Our organization Example.com has a number of microservices that it utilizes for some of its core business applications.

Microservices can call other microservices, and microservices can be utilized by multiple composite applications, directly or indirectly. The composite applications themselves may become microservices themselves at some point as well. We’ve discussed how Example.com’s Benefits is outsourced to a SaaS provider, so one could overlay on-premise and cloud ovals in this diagram as well.

Where does externalized dynamic authorization fit within this architecture? To answer that question, let’s first evaluate whether Externalized Dynamic Authorization itself could be modeled as a microservice. This may shape our perception of where Externalized Dynamic Authorization fits within the microservices world.

Externalized Dynamic Authorization Itself as a Microservice

To determine whether Externalized Dynamic Authorization itself could be a microservice, let’s look at some characteristics of the Policy Decision Point (PDP):

• Stateless: No PDP ever has to depend on another PDP for its decision rendering.
• No Write: PDPs are nearly always read-only to its attribute data sources (PIPs).
• Standards-based: XACML implementations of dynamic authorization don’t have to worry about different approaches to calling the service.
• Bounded Context: Axiomatics provides namespaces for attributes so that even if the same attribute name means different things in different business domains, the microservice can still service them all. For example, if the attribute “state” has a geographic meaning for Employee Data, while Support Ticketing uses “state” to indicate the status of a Ticket, using namespaces like com.example.ticket.state can maintain these boundaries.
• Disconnected: The PDP can operate independently from the Policy Administration Point (PAP).
• Immutable without Host Affinity: One could stand up multiple PDPs without having to change configurations each time.
• No Shared Libraries: Axiomatics provides a RESTful interface for its PDP authorization decision service.

These features are consistent with the “Commandments” of microservices, and indicate that the PDP certainly could be modeled as a microservice. If each business domain wants to decentralize its policy modeling and authoring as well as the policy decision service, the PAP could also be modeled as a separate microservice. However, utilizing the multi-tenant capability of Axiomatics may enable utilizing a shared service model for the PAP. Containers like Docker are often utilized in the build out microservices. Although not available in the marketplace yet, the Axiomatics solution could certainly run in a container.

By its nature, dynamic authorization relies on other attribute sources for its attribute-based access control (ABAC) policies. PIP sources may use shared services like Active Directory, but because the PDP is read-only to the PIP, the PDP still adheres to the microservices model. If the PDP utilizes a local database (to the consuming microservice) for a PIP, and that schema is in flux, one must be able to automate the PDP definition for talking to that database PIP. Axiomatics features an API for modifying its Attribute Connectors, as well as import/export capability, providing multiple options for automation of this configuration.

This evidence supports the assertion that Axiomatics could be modeled as a microservice. We now have a couple of new hexagons within our diagram. Any microservice or composite app could call the authorization microservice as needed.

The Employee Data hexagon encapsulates the Resource Server implemented as an API Gateway in our earlier post. This is how the Example.com custodians of the Employee Data microservice have architected their API security. The Opportunities microservice may adhere to the “Smart endpoints and dumb pipes” principal that Martin Fowler espouses and rather than utilize an API Gateway, and may incorporate their OAuth Resource Server and Policy Enforcement directly within their service. The point is that there is no hard answer to where the PEP needs to be.

Performance is sometimes cited as a concern with using an external PDP. The whole notion of microservices is built upon a distributed architecture, so why is authorization different? Since the Externalized Dynamic Authorization service has all of the characteristics of a good microservice (assuming fault tolerance is done properly), then performance concerns shouldn’t be any different from any other microservice.

Let’s look at the consumption of dynamic authorization by microservices and the composite application that is made up of microservices.

Microservices Consuming Dynamic Authorization

Determining whether dynamic authorization is best enforced at individual microservices or at the composite application (Made up of multiple microservices) is a matter of design. Externalized Dynamic Authorization could be utilized at the presentation layer of the composite app, or at various data filtering and masking layers.

OAuth is the defacto standard for trust in a microservices model today. Microservice developers may be more comfortable with OAuth than XACML and view the introduction of Externalized Dynamic Authorization and see the introduction of the latter as a threat or a burden. If the implementation of an API Gateway or a Policy Enforcement Point is viewed as too ‘heavyweight’ for a microservice, then one may have to consider working within the OAuth model completely. Another reason might be that the trust model with OAuth may already be blessed and introducing the PEP may be cause for re-certification, which may be too significant of a barrier.

In this case, Externalized Dynamic Authorization would need to be incorporated into the OAuth validation. One approach in this case is to have the OAuth Authorization Server leverage the PDP as part of its validation step. The PDP could return a set of OAuth scopes that the client can execute on behalf of the Resource Owner.

The advantage to this approach is that there is no dynamic authorization enforcement (PEP) at the microservice. The microservice only does “pure OAuth” in that it enforces authorization on scopes only. As discussed in Part 2 of this series, scopes only provide a consent model, not a true Mandatory Access Control model.

Summary

This paper has described ways that dynamic authorization can be implemented in conjunction with OAuth and OpenID Connect. Both standards, and especially OIDC, provide great context for the PEP to leverage when formulating an authorization request. Neither standard, however, provides the capability of authorization in the sense that protects the organization’s data. Scopes provide a way for consent to be delegated by the data (Resource) owner, but does not provide a construct for defining and enforcing rules set forth for compliance policies like PII handling, in the way the XACML standard is capable. XACML is the key standard for authorization and is complementary to OAuth and OIDC.

Microservices is a shift in the API architecture, emphasizing a decentralized, independent, and business-domain-centric set of service building blocks. Externalized Dynamic Authorization itself can be factored as a microservice, to be consumed by other microservices and composite applications. Design decisions may drive where the policy enforcement point may reside in a microservices architecture, depending on how much ‘smartness’ is incorporated into the endpoints.

Axiomatics is the leading Externalized Dynamic Authorization vendor providing solutions for API and data security. Axiomatics features lend itself to “dockerize” authorization as a service, as well as easy integration with API gateways. Its namespace capabilities enable bounded context and its RESTful interfaces lend itself to any modern API architecture.