Multi-region deployments usually take into account factors such as scalability, availability and region-specific restrictions on systems and/or data. When region-specific restrictions such as storage of Personally Identifiable Information (PII) are applicable, the deployment strategy needs to consider some kind of region affinity, so that users are using infrastructure located in their geographic region.
The Curity Identity Server includes components that can be used in such scenarios, namely:
Zones. Each service role in Curity is bound to a zone, which usually represents a geographic region. A zone transfer mechanism that can be used to extract session data from one service role into another. A zone-aware data source, which delegates to different backing data sources based on the zone of the current service role. Wrapped tokens, which allow non-sensitive data to be included in a JWT token string, but sensitive token data to only be available via introspection.
The following sections detail how these features can be used together.
When a user accesses Curity without any session context (e.g. first time access), mechanisms such as sticky sessions at load balancers can’t be used yet. This means that the user may be accessing a Curity service role that is not bound to the intended zone. The Zone Transfer authentication action can be used to detect and recover from this situation. The process goes as follows:
A user navigates to the Curity Identity Server URL in the browser and is directed to a service role in the wrong zone.
The authorization request triggers an authentication pipeline that includes the Zone Transfer action.
The Zone Transfer action compares the zone attribute of the current authentication attributes with the Zone of the current service role. Since the values are different, the authentication action initiates a zone transfer:
zone
The zone HTTP cookie is set with the value of the intended zone. The current session state is extracted. The browser is redirected back to the authentication endpoint in Curity.
The redirect goes through an infrastructure component such as a load balancer or a reverse proxy which uses the zone cookie to direct the user to the correct Curity server.
The session state is restored and the authorization flow is resumed.
Since the Zone of the current service role now is the intended one, the Zone Transfer authentication action allows the flow to proceed.
The user authenticates and the authorization flow ends, returning control to the client application.
When the front-channel leg of an authorization flow is done, the resulting artifacts are used by the client in back-channel requests, either to complete the flow in Curity (e.g. authorization code grant) or to access protected resources. In either case, the same region affinity concern arises. This is where wrapped tokens can be helpful. Using access tokens as an example, the process might go as follows:
Note
Wrapper JWTs don’t include any claims resulting from the authorization flow unless explicitly configured, even if other claim mappings are defined for the wrapped token (which is likely the case).
When data needs to be kept in specific regions, the different data sources used by Curity need to be configured accordingly. Instead of defining different configurations for each region, the multi-zone data source can be used; at runtime, it delegates data access to other data sources, based on the zone of the current service role. Configuration for such a scenario may be done as follows:
This ensures that any data access (e.g. Sessions, Accounts) will be scoped to the correct zone, while keeping a single configuration for the different servers.