Dynamic User Routing

Intro

The Multi-Region Deployment article discusses some design choices for global deployments of the Curity Identity Server. This article describes an intelligent routing pattern to ensure user data is managed in the recommended way and that the system is reliable for end-users:

The key behavior is to enable a reverse proxy to read the user's region from tokens or cookies and route requests accordingly. When the region is unknown, such as during the early stages of authentication, a default routing occurs until the user is identified.

Global Deployments

Hosting an Identity and Access Management (IAM) system in multiple regions can be challenging since software companies need to meet several tricky requirements:

Data Management

Replication

In previous years, it was a standard practice to use database replication to share all user data across all regions. This works in theory, but there is always the potential for an OAuth request to be received and depend on data that has not yet been replicated.

Sovereignty

Some countries may have strict rules regarding where their citizens' data can be stored, preventing global replication. This tends to require the partitioning of user data by legal boundaries.

Configuration

The IAM system will contain many intricate settings for OAuth clients, authentication, and token issuance. It is recommended only to maintain a single copy of this data.

Storage Design

It can therefore make sense to store most IAM data separately per region, with the exception of configuration settings:

Associating Users to Regions

Identifying a User Before Authentication

The technique is to first identify the user during the early stages of authentication, perhaps via a screen that captures a user identifier. Since this is presented before the user is known, at this point, the request may be in the wrong region:

Completing Authentication

Once the user name is submitted, logic will run to look up the user's region and issue it in a cookie. This enables subsequent OAuth requests to be routed to the correct region for the user. Authentication can then complete, using a local data source to look up the user account and verify credentials:

Associating Users to Regions

The logic to map users to regions could potentially be performed in multiple ways, and it will need to use the Identity Server's extensibility features. One option might be a globally replicated database that contains a mapping of user IDs to region values:

• For systems where an administrator provides access, values could be provided as part of the process that grants user access.
• For systems where users sign themselves up, a custom authentication action could prompt the user for their region when it is unknown.

Subsequent OAuth Requests

After user authentication, the user's region can then be supplied in all subsequent OAuth requests:

• Front channel GET requests can provide it in an HTTP Only cookie.
• Back channel POST requests can provide it in OAuth token fields.

For POST requests, several different messages could be sent from applications:

• Authorization Code Grant
• Refresh Token Grant
• User Info
• Introspection
• Revocation

Dynamic Routing

Reverse Proxy Entry Points

It is recommended to expose endpoints of both the Curity Identity Server and APIs via a reverse proxy. This makes it more difficult for an attacker to gain access to data sources. Once this infrastructure is in place, you can also leverage the reverse proxy for other features, including dynamic routing.

Wrapped Tokens

By default, access tokens, refresh tokens, and authorization codes are opaque values and unreadable by the reverse proxy. This can be overcome by configuring the Authorization Server to issue these values as "wrapped" JWTs. These are similar to opaque tokens in that they are confidential and do not contain any sensitive claims:

{
  iss: http://login.example.com/oauth/v2/oauth-anonymous
  azp: myclient
  jti: P$b2116bfc-4aaf-4ab9-b633-61bc3ed6897c
  iat: 1622813187
  exp: 1622813487
  region: us
}

Regional OAuth Request Routing

The region received in OAuth requests is not sensitive data and is designed to enable a reverse proxy to perform intelligent routing. Most reverse proxies support the use of plugins, and only a simple plugin is needed to read the cookies from front channel requests and the tokens from back channel requests.

Regional API Request Routing

At Curity we also recommend hosting a reverse proxy in front of your business APIs and implementing the Phantom Token Pattern. If tokens contain the user's region, you can also implement dynamic routing for API requests to enable business data to be stored regionally when required.

Simplified Infrastructure

The dynamic routing pattern requires only a simple plugin to be developed in your reverse proxy. You then no longer need to depend upon complex infrastructure solutions, which may be difficult to make fully reliable:

Performance Considerations

In the edge case scenario of a user visiting another region, logins and OAuth requests will run slightly slower due to the additional latency. This is often considered an acceptable trade-off since performance will improve when the user returns home.

Example Implementation

The Implementing Dynamic User Routing how-to provides step-by-step instructions on configuring dynamic user routing using the Curity Identity Server. This includes an end-to-end solution you can run on a standalone computer to evaluate the architecture.

Conclusion

Hosting a global IAM system in multiple regions can be challenging. Using the routing capabilities in your reverse proxy can provide a clean way to keep your data separated by region. This can also reduce the need for more complex infrastructure solutions.