Multi-region Deployment for WSO2 Identity Server - Part 2
- Johann Nallathamby
- Director - Solutions Architecture - WSO2
In this article we will continue the discussion on multi-region deployment use cases for WSO2 Identity Server (IS) from part one in this series. If you haven’t already read the first part, we suggest that you read it before you continue with this article.
We identified 3 types of multi-region deployment use cases for WSO2 IS in the previous article:
- Replicate identity and configuration data across all regions
- Replicate only configuration data across regions but partition identity data by region
- Partition all data according to the region they belong to
In the first part we deep-dived into use case 1. In this article, we will explore use cases 2 and 3. As in the previous article, we intend to stay away from using any database replication techniques. These two use cases will ensure multi-region high availability and confine the data of WSO2 IS to the region that it belongs to, although we will have to compromise on achieving minimal response time.
Multi-region Deployment for Use Case 2 - Replicate Only Configuration Data Across Regions but Partition Identity Data by Region
Before discussing this use case, a definition of what is meant by resident identity provider is needed. This phrase is respective to a user, and refers to the identity provider where a user identity resides and is responsible for asserting the user’s identity with claims.
The deployment architecture and configurations for this use case will remain more or less the same as use case 1 in the previous article. However, there are some differences to be highlighted.
In this deployment, since identity data is not replicated across regions, any identity related operations such as authentication, password updates, account updates, etc. are restricted to the respective user’s resident identity provider, while application related operations such as single sign-on and federation, application entitlements, etc. could potentially happen with all the regional identity providers and/or authorization servers.
Contrary to use case 1, one region cannot act as a disaster recovery (DR) site for another region, because then the objective of partitioning identity data across regions is not achievable. Therefore each region must have its own dedicated DR site.
If the regional authorization server/identity provider of a user and the resident identity provider of that user are different, all single sign-on and federation requests from an application to that regional authorization server for the particular user will have to be federated with the respective user’s resident identity provider using identity federation protocols to authenticate the user.
As with identity syncing patterns in use case 1, we can identify the following two topologies to setup identity federation between the identity providers:
Fully Connected Mesh
In this topology each regional identity provider/authorization server will maintain the full list of users and their regions in order to federate with the respective resident identity provider.
Hub-and-Spoke
This topology introduces an Identity Federation Hub that is responsible for managing users and their regions, and federate with the respective resident identity provider. For example, users and their regions can be managed in the form of a lookup table. In order to mask the usernames, we can hash and store them.
When federating from a regional identity provider or federation hub to a resident identity provider, we need to use the region specific DNS URLs. However, cookies which are written to the user agent to track user activity needs to be written with the global domain, otherwise these cookies cannot be used to track user sessions across regions.
The following illustration shows how the sequence diagrams for single sign-on and federation for this use case will look like. We will use OpenID Connect as an example to illustrate the flow between the application and the regional identity provider, as it is the most complex protocol out of the single sign-on and federation flows. However, the use case is applicable to any other single sign-on and federation protocols as well such as SAML2 SSO, WS-Federation Passive Requestor Profile, and CAS. We will only look at the sequence diagrams for the case where the regional identity provider/authorization server is not the resident identity provider of the respective user. For the other use case, the sequence diagram will look similar to regular single sign-on and federation flow.
Figure 1: Sequence diagram for OpenID Connect flow with Identity Federation under mesh topology
Figure 2: Sequence diagram for OpenID Connect flow with Identity Federation under hub-and-spoke topology
In part 1 of this series, we looked at a special problem with OAuth2 for use case 1. The same problem is applicable for use case 2 as well. As with use case 1, there is a chance that the OAuth2 authorization request and OAuth2 token request are served by two different regions, which gives rise to this problem. In other words, the regional authorization server of the user and the regional authorization server of the application are not the same. This problem will not occur for mobile applications because the user and application instance are in the same region at any given time, but it could happen for web applications if the application instance is running in a different region to that of the physical user. Therefore the same solutions discussed in part 1 are applicable here as well.
We will not look at sequence diagrams for all 4 solutions as we saw in use case 1, but will select and apply solution 3 from that same list to the same problem in this case, combined with the hub-and-spoke topology, and see what the sequence diagram looks like when this condition occurs. You should be able to derive the sequence diagrams for the other 3 solutions we discussed easily, as well as sequence diagrams for all 4 solutions applied on the mesh topology.
Figure 3: Sequence diagram for OpenID Connect flow where the physical user and application instance are from different regions combined with the hub-and-spoke topology for identity federation
Multi-region Deployment for Use Case 3 - Partition All Data By The Region They Belong To
Prior to the discussion of this use case, a definition of what is meant by resident authorization server is needed. This phrase is respective to an application or service provider and refers to the authorization server where the logical representation of the application or service provider resides, and is responsible for authenticating and authorizing the application or service provider for the requested access.
The deployment architecture and configurations for this use case will remain more or less the same as Figure 1 in use case 1. However, there are some differences to be highlighted.
In this deployment, since neither identity data nor configuration data is replicated across regions, any identity related operations such as authentication, password updates, account updates, etc. are restricted to the respective user’s resident identity provider, while application related operations such as single sign-on and federation, application entitlements, etc. are restricted to the respective application’s resident authorization server.
For the same reason as in use case 2, each region must also have its own dedicated DR site.
Syncing configuration data within a region could be done either manually or via multi-master replication of the database. Given that multi-master technique across regions is supported by the database, it could also work in this case because, the number of nodes within a region will be typically limited to 2.
In the case where the regional authorization server of a user, and the resident authorization server of an application the user is trying to access are different, all single sign-on and federation requests from that application to that regional authorization server for that particular user will have to be redirected to the respective application’s resident authorization server to validate the application.
To identify the resident authorization server we will use the self-contained client identifier pattern. The self contained client identifier can be the service provider entity id in SAML2 single sign-on, client_id in OAuth2/OpenID Connect, and so on.
When redirecting from the regional authorization server of the user to the resident authorization server of the respective application, we need to use the region specific DNS URL.
We will only look at the sequence diagrams for the case where the regional identity provider/authorization server is not the resident identity provider of the respective user.
The following diagram shows how the sequence diagram for single sign-on and federation for this use case will look like. We will use OpenID Connect as an example to illustrate the flow between the application and the regional authorization server in this case too. However, the solution can be extended to any other single sign-on and federation protocols as well. We will only look at the sequence diagram for the case where the regional identity provider/authorization server of a user and the resident authorization server of a particular application that user is trying to access are different, combined with the mesh topology. Yet again, you should be able to derive the sequence diagram for the solution with the hub-and-spoke topology.
Figure 4: Sequence diagram for OpenID Connect flow where regional authorization server of the user and resident authorization server of the application are different, combined with the hub-and-spoke topology for identity federation
The special problem for OAuth2 we looked at in use cases 1 and 2 could also occur in use case 3l. In order for this problem to occur, the authorization call and token call have to be served by two different authorization servers. In use case 3, the authorization code is always issued from the resident authorization server. If the resident authorization server and the regional authorization server of the application instance are different, this problem could occur. Although rare in web applications, it is possible if there is a multi-region web application which doesn’t have an authorization server in some of its regions. This problem is more common in mobile applications, where the mobile device may travel with its user across regions.
To overcome this problem, applications have to make the token calls using the region specific DNS URL. One solution is to provide the token endpoint URL of the resident authorization server to the application through a configurable parameter. There are some advantages to this as well, such as:
- No extensions required in WSO2 IS
- There could be always only one call over the network to the token endpoint to get an access token
Apart from the above, the solutions containing self-contained authorization codes discussed in use case 1 will also work for this use case. However, in this situation, the resident authorization server is fixed in relation to an application and cannot change with each request. In this instance using self-contained authorization codes could be considered over-engineering. As such, instead of using self-contained authorization codes, we will use a self-contained client_ids to encode the domain of the resident authorization server that issued the client_id. The pros and cons of each solution discussed in use case 1 will remain the same for this use case as well. For example, a self-contained client_id may be a JSON String in the following format:
{"random":"abcd…1234","oauth2_authz_server":"https://oauth2.wso2.eu/"}
The following diagram demonstrates what the sequence diagram will look like for the use case when this condition occurs, combined with the mesh topology. You should be able to derive the sequence diagram for the solution with the hub-and-spoke topology easily.
Figure 5: Sequence diagram for OpenID Connect flow where regional authorization server of the application is not the resident authorization server combined with hub-and-spoke topology for identity federation
There are other Restful APIs in WSO2 Identity Server which are protected using the OAuth2 access tokens, such as OAuth2 Token Introspection endpoint and OpenID Connect UserInfo endpoint, which are accessed by the OAuth2 clients and OAuth2 resource servers. In order for these OAuth2 clients and OAuth2 resource servers to access the correct region of the OAuth2 authorization server, we have to inform them about the region that was responsible for issuing the token. To convey this information we have to use self-contained access tokens. The self-contained access token will encode the domain of the resident authorization server that issued the access token. For example, a self-contained access token may be a JSON String in the following format:
{"random":"abcd…1234","oauth2_authz_server":"https://oauth2.wso2.eu/"}
Summary
This article takes a closer look at the remaining two multi-region deployment use cases of WSO2 IS that we alluded to in part 1 of this article series. Similar to the first part, we’ve looked at how we could support these use cases for organizations that have global IT administrations without relying on database replication techniques.References
[1] Multi-region Deployment for WSO2 Identity Server - Part 1