Globally, there are multiple data localization rules and compliance frameworks which affect multinationals. Different countries come with various forms of regulation. The biggest challenge for these businesses is to clearly understand what types of data can be stored in the cloud and how to manage data to comply with country-specific regulations. I will share a real example that will use Okta as the Customer Identity and Access Management (CIAM) platform.
Let’s jump into the scenario of a multinational company called ACME which conducts business in EMEA, APAC, and the US. ACME stores and manages customer-sensitive (PII) data but needs to adhere to local regulations within their operating countries, requiring a data residency solution. ACME currently leverages a mixture of SaaS applications and on-premise platforms.
Focusing on Okta as the Customer Identity Access Management (CIAM) platform, PII data is at the core of a user profile. A rich and proper user profile will require at least some necessary personal data such as name, telephone number, and email to be able to identify and authenticate a user. For the consumer-facing application to provide rich, consistent, and meaningful digital experiences to the consumer, the user profile stored within the CIAM platform will drive these experiences.
By integrating Okta with the InCountry Data Residency platform, the solution can address the data residency requirements pertaining to different countries. Below we discuss several steps that were taken for a “Create User” POC and describe exactly this was achieved.
By signing up with a free InCountry service, you will be able to have access to the InCountry Data Residency service.
Once you have completed signing up, you should be able to see the global data localization dashboard which will allow you to see immediately which countries are hosting the PII data you’ve stored within the platform as well as access data usage metrics.
To trigger the saving of PII data from Okta to InCountry, the Okta platform provides a native webhooks integration capability that gets triggered when certain Okta events are transpired within the CIAM platform. These events are called Event Hooks. Through Event Hooks, you can configure an external web service or webhook that gets executed and in this scenario, we will use the Okta create user event type to trigger the InCountry service.
Every time a user is created in the Okta backend, this fires a “Create User” event. Here is an example of the create user event which already has created the user account within Okta whenever a user signs up in your digital platform.
During the user creation event, The PII data which was initially captured and stored within Okta will be sent to InCountry’s Point-Of-Presence (POP) for storage in a JSON format and the JSON body is stored at rest in the InCountry POP. Not only does the InCountry POP support secure storage of regulated data at rest, but also the processing of that data e.g CRUD operations and application workflows.
Given Okta is calling an external webhook during the user creation event, you can create or design a business logic to decide whether the customer’s PII data should be redacted and the specified PII data stored locally in a specific country.
We will be using Okta Workflows as the business logic execution provider for the webhook. Okta workflows will call the InCountry API to redact the sensitive PII fields in a user profile.
Here is an example of the data now displayed in a redacted format given that the un-redacted data needs to be stored in a specific country using InCountry’s Data Residency service.
To un-redact the data, Okta provides another webhook capability called ‘In-line hooks’. During the application authentication process, in order for the redacted data to be displayable and readable to the user, synchronous “Inline Hooks” are used to reverse the redaction of data. The application integrated with Okta will leverage OIDC & OAuth 2.0 standards through scopes. Okta will be pre-configured with specific custom scopes, which will determine if the “In-line Hooks” needs to be executed or not. Once the defined scope sent by the application to Okta is provided, this will trigger the reverse redaction process.
The authentication flow will now leverage the external web-service or web-hook which will trigger a business logic that will leverage the InCountry service to extract the un-redacted data in real-time.
To do this, the webhook will just send a key-value pair wherein the key will be the Okta user id and the value will be the country where the said data is stored upon.
The key-value pairs stored on the InCountry POP, relating to a specific Okta user. This generates the JSON object and body which contains the PII information that is reverse redacted. The data is then passed back to Okta so that it can be presented in a readable format.
The final result is that the reverse redacted data is now readable to the application using OIDC and OAuth 2.0 standards wherein the redacted data are represented in a readable format within the ID and Access JWT tokens.
In summary, Okta and InCountry provide an end-to-end solution that will allow you how to handle PII data within your CIAM platform in a localized manner.
Here’s the complete demo explained in this video as part of my Tech Monday video series