Security Patterns for Heterogeneous WSO2 API Management Clusters — Part 2

Security Patterns for Centralized Management Plane — Decentralized Data Plane and Control Plane

Introduction

In the first part of this two-part article series I’ve introduced “heterogeneous API Management clusters”, its well known examples and its different patterns. I’ve then gone on to discuss the “API Store Separated Clusters” deployment pattern in detail, how they can be implemented in WSO2 API Manager and shortfalls in implementing them in WSO2 API Manager. In this part I will discuss about “Key Manager Separated Clusters” deployment pattern.

Figure 1: Heterogeneous WSO2 APIM Cluster Deployment Patterns

Key Manager Separated Cluster Deployment Patterns (#3,#4,#7,#8)

In the Key Manager separated patterns, there are mainly 3 important security properties that users look for.

1. Avoid sharing of the OAuth 2.0 credentials (e.g. client_id, client_secret) between Key Managers at the physical data store level. This physical siloing of OAuth 2.0 credentials will ensure that only the applications that are corresponding to a Key Manager can obtain an OAuth 2.0 access token from the particular Key Manager.
2. Restrict the ability to validate OAuth 2.0 tokens to the relevant Key Managers at the physical data level.
3. Avoid sharing of application consumer accounts between Key Managers at the physical data store level. This physical siloing of application consumer accounts will ensure that only the users that are corresponding to a Key Manager can log in and authorize an OAuth 2.0 access token.

Properties #1 and #2 could not be achieved with WSO2 API Manager up to version 3.1.0. This was because the solution was designed to work with only one logical Key Manager in the entire deployment.

In patterns #3 and #4 we also have an additional limitation. Some of the communication between the API Store and the Key Manager rely on the sharing of the database between these two components; they don’t exclusively communicate over APIs. With WSO2 API Manager 3.2.0 improvements were also done to decouple the tight database integration between API Store and Key Manager and communicate exclusively over APIs.

Even though the above desired properties were not achievable with physical separation, as the next best option there were ways to achieve property #2 with logical separation. The methods of achieving this logical separation depend on the access token types that are being used.

Opaque Access Tokens

• With opaque access tokens you can use group-based scope authorization (one unique group for each Key Manager), to ensure only tokens that are authorized by users who belong to a designated set of groups in a particular Key Manager can be validated by that Key Manager.
• If the group names in question are not unique across the Key Managers, then make sure you use a unique user store domain name across all the Key Managers and then qualify the group names with the user store domain name during token validation.
• If the usernames are not unique across the Key Managers, then make sure you use a unique user store domain name across all the Key Managers and and then qualify the usernames with the user store domain name during token validation.
• If you are working with the PRIMARY user store, then make sure you give explicit unique domain names for the primary user store in each of the Key Managers.
• Renaming the ‘everyone’ role in each of the Key Managers to something else that is exclusive only to that Key Manager, and using that designated ‘everyone’ role construct to identify users governed by the different Key Managers will allow you to leverage the implicit assignment of all the users in the Key Manager to this role.

Self-contained JWT AccessTokens

As with opaque access tokens role-based authorization also would work here. However, a more efficient approach would be to have unique keys to sign the self-contained JWT access tokens so that each Key Manager is able to validate only the tokens that were issued by the same. This approach is more compliant than role-based authorization to fail-fast principle.

In Gateway separated deployments (#4,#8) each gateway is configured to its corresponding Key Manager for token related operations such as token validation.

However, with WSO2 API Manager 3.2.0 onwards the ability to work with multiple logical Key Managers with physical data store separation has been introduced. This allows users easily achieve properties #1 and #2.

Property #3 seems quite straightforward to achieve given the ability of separating the users into physical user directories and integrating each of the user directory with its corresponding Key Manager.

However, sometimes there can be instances that the same set of users may be required to authenticate to more than one Key Manager. For example, external application consumers in a dedicated user directory who are required to authenticate to both an internal and external API Management solution.

There are two ways to achieve this.

1. Integrate the user directory to multiple Key Managers as a read-only directory
2. Use identity federation and home realm discovery to federated between Key Managers

Though upholding of property #3 may imply that property #2 also holds true, it is as a defense-in-depth mechanism that users like to have all 3 levels of separation in their deployment.

Summary

In this second part of the two-part article I’ve discussed the “Key Manager Separated Clusters” deployment pattern in detail, how they can be implemented in WSO2 API Manager and shortfalls in implementing them in WSO2 API Manager. WSO2 API Manager is an industry-leading free and open source API Management product, released under the most business friendly Apache 2.0 license, which has a wide range of capabilities to support different heterogeneous API Management cluster deployment patterns to meet varying business needs.