Security Patterns for Heterogeneous WSO2 API Management Clusters — Part 1

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

5 min readMar 3, 2021

Introduction

WSO2 API Manager supports a variety of deployment patterns for varying business and technical use cases [1,2]. While the all-in-one deployment pattern is at one end of the spectrum as the most simplest deployment pattern, the fully distributed deployment is at the other end of the spectrum as the most flexible deployment pattern. However, in between these two are a wide variety of deployment patterns with varying levels of distribution of components that users may consider from in order to have the most optimal deployment considering aspects such as complexity, flexibility, security and cost.

While the level of distribution of components is one dimension of a deployment, another dimension is the number and types of clusters of each component in a deployment.

Sometimes in organizations there can be requirements for more than one API Management platform within an organization. This could be the case due to security, the independent nature of the projects and/or project lifecycles and may be as measure to de-risk the projects due to interdependencies. While some organizations may go down the path of complete physical siloing of these platforms, some organizations may choose to share certain components between these platforms while separating out the rest of the components into different clusters for each platform due to reasons like cost and maintenance overhead. These are the patterns we are going to collectively refer to as “heterogeneous API Management clusters”.

Some of the popular heterogeneous API Management cluster deployment patterns are:

Internal and External API Management [3]
Internal and External Application Consumers
Multi-region API Management [4,5,6]
Hybrid API Management [7]

In this two-part article series, I am going to take a closer look at some of the security characteristics that organizations desire to achieve with these heterogeneous API Management cluster deployment patterns.

Heterogeneous WSO2 API Management Clusters

Components that are usually shared among the clusters are the API Publisher, Admin Portal, Traffic Manager and API Analytics. Components that usually considered to be set up dedicated are the API Gateway, API Key Manager and API Store.

Based on the above we could classify the following types of heterogeneous API Management clusters.

Figure 1: Heterogeneous WSO2 APIM Cluster Deployment Patterns

Pattern #1 is the basic WSO2 API Manager deployment pattern without distributing any components. Pattern #2 is the distributed API Gateway clusters deployment pattern [8]. Similarly in patterns #4, #6, and #8 also we have the distributed API Gateway clusters aspect. The implications of this aspect doesn’t change across these 4 patterns. Therefore for ease of analysis we will focus our analysis on the variations shown by the blue boxed area.

API Store Separated Cluster Deployment Patterns (#5,#6,#7,#8)

In the API Store separated patterns there are again mainly 3 important security properties that users look for.

Avoid sharing of API consumer accounts between API Stores at the physical data store level. This physical siloing of accounts will ensure that only the authorized API consumers corresponding to an API Store can log in from that particular API Store.
Avoid sharing of APIs between API Stores at the physical data store level.
Avoid sharing of the applications (e.g. client_id, client_secret) between API Stores at the physical data store level. This physical siloing of applications will ensure that only the auhorized API consumers corresponding to an API Store can access applications from that particular API Store.

Avoid Sharing of API Consumer Accounts

Property #1 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 API Store.

If you choose to leverage the inbound identity federation capability in API Store to federate with an external identity provider instead of using local authentication —

If there is a single external identity provider configure each API Store as a unique service provider in the external identity provider and control user access to them based on conditional access control policies in the identity provider.
If there are dedicated external identity providers configure each API Store with its corresponding identity provider for inbound identity federation.

Avoid Sharing of APIs and Applications

Property #2 and #3 however cannot be supported as of the latest version of the WSO2 API Manager (v3.2.0). This is mainly because the WSO2 API Management solution is designed to work with only one logical API Store in the entire deployment (multiple API Stores are only supported for API advertising[9] purposes and not for API subscription).

Tight Coupling between Components

One more reason for not being able to achieve #2 and #3 is the tight coupling of the API Publisher and the API Store at the data store level where some of the communication between the two components happen via the shared database; they don’t exclusively communicate over APIs. Also the following communication happen via the shared database as well:

API Publisher and Traffic Manager (Event Hub) communicate via shared database for API related changes.
Admin Portal and Traffic Manager communicate via shared database for throttling policy definitions.

Therefore transitively these reasons impose an additional constraint in the deployment that the datasources for API Store, API Publisher, Admin Portal and Traffic Manager have to be shared.

Monolithic Datasource Configuration

One of the limitations in the WSO2 API Manager as of the latest version (v3.2.0) is that, you don’t have modular datasource configurations for each profile/capability so that we can share datasource between different components selectively. For example, if the datasource configuration for the applications can be independently configured in the API Store, we could have configured separate datasources for this in each API Store while sharing the other datasources between the API Stores, API Publisher, Traffic Manager and Admin Portal. However, as of now there is only one large shared datasource that can be configured and therefore the API Stores cannot be separated out with dedicated datasources for applications for each.

Logical Separation with RBAC

Even though the desired properties #2 and #3 cannot be achieved with physical separation, as the next best option we can achieve the same with logical separation using role-based authorization to control visibility and subscription capability of APIs in an API Store [10,11].

You may realize that property #1 may also imply that you can’t view APIs, subscribe to APIs and view applications in an unauthorized API Store. However, it is as a defense-in-depth mechanism that users would like to have all 3 properties in their deployments.

Summary

In this first part of the 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 the next part I will talk about “Key Manager Separated Clusters” deployment pattern.