Externalized Dynamic Authorization in a [Micro]Services World

Axiomatics   ·   Monday, December 5th, 2016

Part 1: OAuth and OpenID Connect Come Together with Externalized Dynamic Authorization

Want the fast track of dynamic authorization in a microservices world? Check out this webinar session.

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.

In order to baseline an understanding of the value of Externalized Dynamic Authorization, we’ll start with an example that will later be applied to an API scenario. This diagram shows an example of an architecture for guarding Personally Identifiable Information (PII):

The Policy Enforcement Point (PEP) performs a request/response before the resource is served to the user Alice. The Policy Decision Point (PDP) has policies that are based on attributes stored in the Learning Management System (LMS) and groups within Active Directory. Once the PDP has verified that Alice has completed her PII Training in the LMS and is a member of HR via Active Directory, a permit is returned to the PEP and the PII resource is granted to Alice.

This example incorporates an attribute-based access control (ABAC) model (PII Training must be complete) with a role-based access control (RBAC) model (user must be in HR). A key benefit to Externalized Dynamic Authorization is the ability harmonize various models to make policies more intuitive and entitlements more maintainable. Many organizations try to model contextual attributes as a role and it often results in role explosion. Managing the training completion flag as an Active Directory group would be unintuitive and redundant. If you think of a role as just a multi-valued subject attribute, then RBAC could be just a subset of a broader ABAC strategy.

The externalization of authorization from the resource is important for business agility. If a mandate is introduced to require two-factor authentication (2FA) for accessing PII resources, the policy can be updated and as long as the PEP provides the additional context, the target resource can be left as is. The flexibility of XACML could enable the triggering of the 2FA based on the response of the PDP, where the PEP is engineered to require additional validation at the point of the transaction.

The diagram above does not reflect the protocols in which the PII resources are exposed to the user or how the PEP is implemented. The number of ways in which resources can be exposed are increasing: API-based approaches are becoming as prevalent as browser/web and 2-tier data access. OAuth 2.0 has emerged as a key standard in providing access to these APIs. Let’s see how this service can be applied to an OAuth flow. The picture below shows the issuance and validation steps in an OAuth 2.0 flow:

Let’s assume that the API client already has an authorization code and is acting on behalf of Alice. The API Client is issued an access token using its authorization code, client credential & client secret, typically. The client then makes a business API call with the access token. The Resource Server, typically an API Gateway acting as an intermediary for the Business Service, validates the access token against the authorization server. The OAuth 2.0 Authorization Server may return attributes about Alice to the API Gateway. Once verified, the Gateway brokers the business API call.

OAuth 2.0 uses the term “Authorization Server” to describe the role of an actor in the various OAuth flows that authenticates the identity of the resource owner, and issues and validates tokens for the API Clients. While the Authorization Server can perform some authorization tasks, let’s assume for this article that the Authorization server just issues tokens and provides context. We will go into the various scenarios where the Authorization Server may play a bigger role in the next portion of this series. XACML terms will be used to describe the various components of the “Externalized Dynamic Authorization service”.

Often, the validate call returns a set of claims / context / attribute values to Resource Server. One pattern of integration with a Externalized Dynamic Authorization service would be to have the API Gateway / Resource Server include a Policy Enforcement Point (PEP).The advantages of this model is that one can define binary authorization (issue permits and deny’s) based on the context returned by the Authorization Server. Context could include OAuth scopes or any subject attributes returned by the Authorization Server.

Where to enforce your PII authorization policies depends on and number of factors and philosophy on security. One common pattern is leveraging the API Gateway, acting as the Resource Server, to implement the PEP within its orchestration layer. This approach reduces the maintenance of the PEP versus applying it to every business service. The API gateway has access to the context provided by the OAuth 2.0 Authorization Server, which might not be propagated to the target service, and generally API Gateways are in a position to handle failures for reasons not related to policy (security, DDOS, etc.)

From the primer, you know that OpenID Connect (OIDC) is built on top of OAuth and the players above really don’t change. OIDC provides all kinds of great ways to get user context via the ID Token and UserInfo endpoint. OIDC, like OAuth, does not however, define how authorization decisions are to be made. The context provided by the ID Token and the UserInfo endpoint can be parsed and used by the PEP to formulate a request to a Externalized Dynamic Authorization decision engine like Axiomatics. Going about writing policy logic with OIDC alone however, will leave organizations embedding authorization logic into the APIs, making them difficult to audit and manage.

Axiomatics can provide Externalized Dynamic Authorization for your business APIs and microservices. How you incorporate the policy enforcement depends on your design. The OAuth Resource Server can act as the enforcement point for binary authorization decisions. The OAuth Authorization Server can pull OAuth scope from the Policy Decision Point to include within access token, once approved by the Resource Owner. OAuth 2.0 provides authentication and contextual attributes that can leveraged in policy decisions in both cases. While OAuth 2.0 and OpenID-Connect also provide authorization capabilities, there may still be a case for supplementing with a more Externalized Dynamic Authorization service. The comparisons are covered in Part 2.

Want the fast track of dynamic authorization in a microservices world? Register for our microservices webinar, hosted by blog author and Services Consultant, Matt Carter, taking place live Tuesday 7/25. More info and registration.