Automated regional routing model
In this deployment scenario, the Strivacity meets data residence requirements by automatically routing customers to the correct country based on its global catalog.
This approach is designed to meet the most stringent data residency and sovereignty requirements. In this setup, Strivacity intelligently routes authentication requests to the appropriate regional Strivacity regional instance based on the customers location—without requiring the user to manually select a region. Personal data (PII) is stored and processed only in the country where it legally must reside, ensuring compliance with strict national data protection laws.
Process flow for automated regional routing using Strivacity global catalog
This solution ensures that, irrespective of what geo-graphic location a user registers or logs in from, that their PII always remains resident in an Identity Store in the country where their PII should be stored.
This approach automatically determines what regional Strivacity instance should process the authentication without the customer needing to choose or decide.
There are three processes in this deployment scenario which are explained in detail below:
1. Authentication Process Description
Process flow for the authentication process for automated regional routing.
Steps
Pre Step
A customer opens the web browser on their device
| Process Step | Description |
|---|---|
| Step 1 | The customer uses their web browser to visit the application in question. Here they may be automatically redirected since there is no existing session, they may need to press a “Login” button, or potentially enter a user identifier and press a “Login” button. |
| Step 2 | Regardless of the process that happens in Step 1, the user will be redirected via their browser to the global catalog utilizing the OIDC federation protocol. And, potentially including a login_hint if one was provided. |
| Steps 3, 3a, and 3b | This is where customer account identification occurs. If a login_hint was provided, Step 3 is followed. If not, 3a and 3b are used to capture a user identifier. Once that has been captured, then the global catalog will, optionally hash this value if stored values are hashed, look up the value to determine the proper Identity Provider to use for the end user authentication event. If this identifier is not found, then refer to the “Registration” sections of this document. |
| Step 4 | This handles the new OIDC redirect to the regional Strivacity instance carrying along a login_hint of the user so that data does not need to be entered again. The inclusion of a login_hint is optional. |
| Step 5 | This is where the customer lands at the regional Strivacity instance to start the authentication process. |
| Step 6 | This step presents the regional authentication process to the customer. This can be different per region. |
| Step 7 | This step validates the customer based on the authentication methods. This step may result in a success or failure of the regional authentication process. Also, Steps 6 and 7 may be repeated based on the number of authentication factors a user needs to complete. |
| Step 8 | Assuming a successful authentication process, will deliver either a code or token set based on the OIDC grant type used. |
| Step 9 | This step will complete the delivery to the global catalog of the code or token set from the regional Strivacity instance. |
| Step 10 | If a code is delivered to the global catalog, this will be the path for the global catalog to request the code / token exchange. |
| Step 11 | If a code is delivered to the global catalog, will be the response of the code exchange for tokens. |
| Step 12 | This will begin the token set or code delivery process to the application that initiated the authentication process. |
| Step 13 | This will complete the delivery to the application of the code or token set from the global catalog. |
| Step 14 | If a code is delivered to the customer facing application, this will be the path for the customer facing application to request the code / token exchange. |
| Step 15 | If a code is delivered to the customer facing application, will be the response of the code exchange for tokens. |
| Step 16 | Tokens are now delivered to the customer facing application and a session can be established, completing the authentication process |
Details on this Process Flow
- PKCE should be available for all OIDC interactions. Both as the main application setup on the global catalog as well as the External Identity Provider setup for the Regional Strivacity instances.
- No data should be stored on the global catalog other than a user identifier (which could be hashed) and a pointer to the proper regional Strivacity instance.
- All data in transit, i.e. claims in the id and access tokens, should be encrypted with regionally defined keys. This does mean the global catalog will need to decrypt and re-encrypt tokens to complete the federation process.
- If user identifiers are hashed in the global catalog, then the process to handle lookup will need to be able to perform this hashing.
2. Regional Account Registration Process Description
Process flow for account registration on the regional Strivacity instance
Steps
Pre Steps
A customer opens the web browser on their device
| Process Step | Description |
|---|---|
| Step 1 | The customer will visit the application in question using their web browser. Here they will initiate a registration process. This process will begin by choosing a geographical location to register their account. Additionally, it may also include collecting an identifier which can be sent to the regional Strivacity instance for starting the registration process. This collection is optional. |
| Step 2 | The customer facing application will send the user to the regional Strivacity instance. Utilizing a registration hint, we can send registration hints the application collected to the regional Strivacity instance. This process will be kicked off using an OIDC redirect. |
| Step 3 | The regional Strivacity instance will receive the incoming registration request and begin the process. |
| Step 4 | The customer will be presented with the registration process to complete. If any registration input was provided via a hint, those fields will be pre-populated. |
| Step 5 | The customers primary identifier will be submitted to the regional Strivacity instance Creation of the account will be contingent on the verification against the global catalog to ensure that this is not a duplicate registration. In addition, the regional Strivacity instance will also send it’s well-known endpoint for storage on the global catalog so it will know how to authenticate this customer. |
| Step 6 | The regional Strivacity instance will attempt to create a registration for the user on the global catalog. This is not a web browser interaction. This step occurs directly between the regional Strivacity instance and the global catalog. |
| Step 7 | The global catalog will respond to the regional Strivacity instance with an error or success message. |
| Steps 4, 5, 6 and 7 | These steps will repeat until a registration of the customer on both the regional Strivacity instance and global catalog are successful. |
| Step 8 | The regional Strivacity instance will respond to the web application with the code or token set from the regional Strivacity instance |
| Step 9 | This will complete the delivery to the application of the code or token set from the regional Strivacity instance. |
| Step 10 | If a code is delivered to the customer facing application, this will be the path for the customer facing application to request the code / token exchange. |
| Step 11 | If a code is delivered to the customer facing application, will be the response of the code exchange for tokens. |
| Step 12 | Tokens are now delivered to the customer facing application and a Session can be established. |
Details on this Process Flow
- A Registration Hint can be used to help seed the regional Strivacity instance registration process.
- All regional Strivacity instances will need the ability to call APIs on the global catalog to ensure proper integration and completion of the registration step.
- Identifier hashing may be completed upon registration in the global catalog.
3. Global Catalog Registration Process Description
Process flow for a global catalog registration process
Steps
Pre Steps
A customer opens the web browser on their device
| Process Step | Description |
|---|---|
| Step 1 | The customer will visit the application in question using their web browser. Here they will initiate a registration process. This process will begin by choosing to register their account. Additionally, it may also include collecting an identifier which can be sent to the global catalog for starting the registration process. This collection is optional. |
| Step 2 | The customer facing application will send the user to the global catalog. Utilizing a registration hint, we can send registration hints the application collected to the global catalog. This process will be kicked off using an OIDC redirect. |
| Step 3 | The global catalog will receive the incoming registration request and begin the process. |
| Step 4 | The customer will be presented with the registration process to complete. If any registration input was provided via a hint, those fields will be pre-populated. Here the user will choose the regional location for their data storage. |
| Step 5 | The customers primary identifier will be submitted to the global catalog. Creation of the account will happen on the global catalog at this time. The remainder of the registration process will occur at the regional Strivacity instance. |
| Step 6 | The global catalog will start an OIDC request to the regional Strivacity instance containing a registration hit with the user identifier that was just collected. |
| Step 7 | The regional Strivacity instance will receive the registration request. |
| Step 8 | The regional Strivacity instance will present the browser with the remainder of the registration process. |
| Step 9 | The customer account will be created on the regional Strivacity instance. |
| Step 10 | The regional Strivacity instance will send it’s well-known endpoint for storage on the global catalog so it will know how to authenticate this customer account. This is happening directly between the regional Strivacity instance and the global catalog. |
| Step 11 | The global catalog will complete its registration record for the given account. |
| Steps 10 and 11 | These steps be omitted if the global catalog is able to source this well-known data in Step 5 |
| Step 12 | The regional Strivacity instance will respond to the global catalog with the code or token set from the regional Strivacity instance. |
| Step 13 | This step will complete the delivery to the global catalog of the code or token set from the regional Strivacity instance. |
| Step 14 | If a code is delivered to the global catalog, will be the path for the global catalog to request the code / token exchange. |
| Step 15 | If a code is delivered to the global catalog, will be the response of the code exchange for tokens. |
| Step 16 | The global catalog will respond to the customer facing application with the code or token set from the global catalog., |
| Step 17 | This step completes the delivery to the customer facing application of the code or token set from the global catalog. |
| Step 18 | If a code is delivered to the customer facing application, this will be the path for the customer facing application to request the code / token exchange. |
| Step 19 | If a code is delivered to the customer facing application, this will be the response of the code exchange for tokens. |
| Step 20 | Tokens are now delivered to the customer facing application, and a Session can be established. |
Details on this process flow
- A Registration Hint can be used to help seed the regional Strivacity instance registration process.
- All regional Strivacity instances will need the ability to call APIs on the global catalog to ensure proper integration and completion of the registration step. Assuming this data is not able to be sourced directly by the global catalog.
- Identifier hashing may be done on registration in the global catalog.
Updated 15 days ago
What’s Next