The modern Security Architecture should be modular and based on Open Standards

This is intended as a high-level view of the components and protocols that make up a modern security architecture for protecting access to micro services.

Micro services that host discrete parts of an organisation’s API need to identify the entities making requests and determine that they have the appropriate permissions to access the resources.

In a token-based security architecture the starting point for determining access is the token passed in with the request. But where did the token come from, how can we trust it and does it have all of the context needed to grant access?

Let’s start with how tokens are minted.

Identity Management System

At the heart of the security architecture is the Identity Management System. This could exist outside of the organisation but is part of a trusted whitelist of providers.

This system is responsible for:

• Authenticating Users (including signing up, managing user lifecycle, self-service, passwords, MFA, FIDO)
• Issuing Tokens (also token introspection)
• User Provisioning to external parties (This can be achieved with SCIM)

The Identity Management System should be OIDC compliant.

When the resource server receives a request that includes a bearer token it must first determine that the token came from a trusted source. Tokens are usually JWTs but they could also be opaque (or by-reference) tokens. In the case of an opaque token the resource server would have to call the introspection endpoint in the Identity server to swap it for a JWT.

There are some standard claims in the JWT that should be checked to ensure the integrity of the token:

• iss (issuer) a url of the token issuer
• aud (audience) is the resource server in the intended target for the JWT
• exp (expiration time) has the token expired
• nbf (not before time) the time at which the token is valid (rarely used)

Finally the resource server must verify the signature of the JWT by using the public key available at the JWKS endpoint provided by the Identity server. These keys can be cached and are usually rotated regularly.

API Management

The use of HTTPS is mandatory for all secure end points. For additional protection the use of mutually authenticated client-side certificates should also be considered although this will bring additional complexity to client access to your APIs. Only expose the interfaces that are necessary. By using an API Gateway you can protect access to internal APIs and control which APIs are exposed externally.

The API Gateway also acts as the the first gate in the security system. Requests that don’t contain a token can be rejected. Tokens that are expired can be rejected. If the tokens are opaque the burden of introspection can be lifted from the resource server and executed by the gateway. Other controls can be handled here too such as IP blacklisting, rate throttling, etc. If the token is not appropriately scoped for the resource it is trying to access then it can be rejected.

Access Management

Once a token has been minted, and verified and the resource server knows it is dealing with a trusted request then it needs to determine the context of the entity making the request.

• Who is the entity making the request? (Bob in payroll)
• What action do they want to invoke? (instruct the monthly salaries)
• When should it be executed? (before 5pm)
• Where are they making the request from? (the head office in New York)
• Why are they making the request? (it’s payday)
• How are they invoking the service? (from a mobile device)

Some of these questions can be answered in the layers before the request gets to the resource server. The access token itself can provide some context with the standard sub claim that tells us who the user is. Custom claims can also be embedded in the token too, such as customerId, accountNumber, etc. However once you start using the token to transport user context then you have to consider whether the JWT should be exposed beyond the API Gateway and perhaps opt for an Opaque token approach.

Attribute-based Access Control (ABAC)

Attribute-based access control (ABAC) uses policies that combine attributes together to make decisions on access to resources. This decouples the resource server from the decision process and allows policies to be set up and maintained out of band.

The most popular standard is XACML (eXtensible Access Control Markup Language) which also has a Json profile. ALFA (Abbreviated Language For Authorisation) is another standard and Netflix have developed the Open Policy Agent which looks promising.

The architecture is comprised of

PEP

The PEP or Policy Enforcement Point: it is responsible for protecting the apps & data you want to apply ABAC. The PEP inspects the request and generates an authorisation request from it which it sends to the PDP.

PDP

The PDP or Policy Decision Point is the brain of the architecture. This is the piece which evaluates incoming requests against policies it has been configured with. The PDP returns a Permit / Deny decision. The PDP may also use PIPs to retrieve missing metadata.

PIP

The PIP or Policy Information Point bridges the PDP to external sources of attributes e.g. LDAP or databases.

Attributes

Attributes can be about anything and anyone. They tend to fall into four different categories or functions

• Subject attributes: attributes that describe the user attempting the access e.g. age, clearance, department, role, job title...
• Action attributes: attributes that describe the action being attempted e.g. read, delete, view, approve...
• Object attributes: attributes that describe the object (or resource) being accessed e.g. the object type (medical record, bank account...), the department, the classification or sensitivity, the location...
• Contextual (environment) attributes: attributes that deal with time, location or dynamic aspects of the access control scenario

OpenId Connect (OIDC)

OIDC is a protocol on top of OAuth2.0 that provides clients with additional information about the logged in entity by including an ID Token as well as a user info endpoint. The access token is used by the client by including it in requests to the resource server but is not intended to be understood by the client.

SCIM (System for Cross-domain Identity Management)

If your system needs to manage users and groups then SCIM provides a means for the Identity server to push CRUD operations to your system. This can also include bulk and patch updates. This could be useful for applying fine-grained security policies in the resource server.

FIDO(Fast IDentity Online)

Use of standard public key cryptography techniques to provide stronger authentication. The User’s device creates a new key pair and registers the public key with the Identity Service. During authentication the client provides proof of possession of the private key. The protocol allows for multiple different user-friendly methods of unlocking the keys on the client machine, such as finger print, voice recognition, facial recognition, etc.