SAP Customer Data Cloud Positions

Global Access

Skip to end of metadata
Go to start of metadata

Overview

Global Access gives your customers a consistent user experience, regardless of their physical location, every time they interact with your brand. With Global Access, when a customer travels to different parts of the world and logs in to your localized sites, they log into their existing account and continue their relationship with your brand. User data is stored at the data center they used to create their account, so that data residency regulations are upheld without compromising experience.  

Global Access is based on storing user data for a site or site group in different data centers, i.e., a single user database with users from multiple regions. 

Use Cases

  • Your company is a global chain of cafes and restaurants, with a loyalty program for registered members. A French registered user is waiting in the Sydney airport for their flight back home and notices your cafe branch. They seamlessly log into their account on the localized Australian website, redeem the discount, order the coffee online and enjoy a great experience with your brand. 
  • You sell quality bikes with a lifetime guarantee for bike frames. A customer from the U.S. is touring China on their bike and has damaged their frame. They log in to the local website, receive information of the nearest shop, provide online proof of purchase via their existing account and order a replacement part, which is ready for them free of charge at the shop the following day. 
  • Your site admin setting up the implementation of SAP Customer Data Cloud for your global brand. They configure a site schema and policies that are shared between all sites in the global site group; they then easily customize language-specific Screen-Sets for registration, login and consent collection, using the UI Builder. If needed, they can set different policies on the child site.

Instructional Video

If you have an SAP logon, you can watch this instructional video about Global Access.


Global Site Groups

Where previously site groups could exist on one data center, global site groups transcend that limitation and can contain sites from any of the SAP Customer Data Cloud data centers. Global site groups are site groups that can belong to more than one data center, allowing users to log in to all the sites in the group from different locations. In addition, you can provide global users with a single sign-on experience. 

Before implementing Global Site Groups, we recommend that you familiarize yourself with site groups and how they work. 

For more information about site groups, see Site Groups and Single Sign-On

Configuration

Global Site

Before creating your global site, you should know which data centers you wish to include there, and which datacenter to select as primary. If the site will be part of a site group, all sites in the group must share the same data centers and the same primary data center (identical data center configuration).

Considerations for determining the primary data center:

  • Performance optimization: the primary datacenter should be the one that holds the majority of the user database (and therefore handles the majority of your SAP Customer Data Cloud traffic for this global site or site group).
  • Residency: if you do not set the user residency, the primary data center will be set as the resident data center for the user.  

To create a global site:

  1. In the Sites section of the Console, select Create Site.
  2. In the Add Site window, specify the following: 
    1. Enter the Site Domain. 
    2. Under Data Residency, select Global Data Center.
    3. Select the data centers to be included in the site: 
    4. Select the primary location.   
    5. Click OK
  3. When creating a site group, repeat the process to create additional sites. All sites in the group must share the same data centers and the same primary data center. When finished, move on to the next section. 

Notes

  • Global API keys are relatively short and start with 4_.
  • When a global site configurations are saved, SAP Customer Data Cloud creates a replica of the site configurations in all the site data centers: site settings, schema, policies, permission groups, user keys, screen-sets. However, the user database is never replicated between data centers.

 

Global Site Group

To create a global site group, after the sites have been created on SAP Customer Data Cloud, aggregate them into a group as follows:

  1. Open the Site Groups manager from the Admin menu of the Console.
  2. Click Create Site Group.
  3. Select the Parent site for this group. 
  4. To enable single sign-on between the group sites, select SSO enabled
  5. Click Add Sites, select all the sites to include in this group, and select Add
  6. Click Create.

 

Making API Calls

When using Global Access, only the following validation types may be used with SAP Customer Data Cloud APIs: 

  • Validate A JWT from SAP Customer Data Cloud - validate the Web SDK response using an id_token. UIDSignature is not supported.
    • Used to validate that the client has an active client session with SAP Customer Data Cloud.

    • Short-lived JWT that holds the UID of the user.

    • Does not hold any personally identifiable information (PII), safe to transfer to 3rd parties.

    • Is not treated as a session, just a proof of ownership.

  • Signing Requests to SAP Customer Data Cloud - sign requests using a bearer token. Signing with a user or application key is not supported. 
    • The RSA private key is stored securely on the server
    • Tokens are short-lived (2 minutes)
    • Tokens are non-reusable (nonce)

In addition to a screen-set based implementation, Global Access supports a REST API implementation. Set the registering user's residency using the dataCenter parameter of the relevant API, such as accounts.initRegistration.

 

Global Registration Flow

Setting the Residency

With Global Access, when a user registers, their data residency is also set. The default is the data center from which they performed their registration; however best practice is to call the setAccountResidency API prior to the registration to manually set the data center. For example, you can display to users a choice of their residency / nationality, then call the setAccountResidency API to pass their selected residency. This will also route the request to the specified data center. The dataCenter is then passed on to the registration flow (via the registration screen-sets, or accounts.initRegistration or socialize.login APIs).

After the user logs in, extract the id_token from the onLogin event and pass it to the server.

The user account includes a dataCenter field that reflects the data center on which their data is stored. 

Changing the Residency

The resident data center cannot be changed by the user, only via a server-side call by a site admin, by calling accounts.global.changeAccountResidency. When an account is being transferred between data centers, no changes may be made to it. In this state, you may only call accounts.getAccountInfo for this account and see that inTransition is returned as 'true'.

Local Consent Collection

Different countries and regions mandate different data compliance regulations. If you are using Customer Consent, you can configure different terms and conditions for each site, and add them to the relevant registration flows. 

Session Management

User sessions may be managed by setting a gltexp cookie that is constructed as a JWT and signed with your RSA secret. For more information, see Managing Session Expiration.

 

Global Access Site Management

In sites that use Global Access, some features of site management in the SAP Customer Data Cloud Console are affected. 

Menu Options

Features that are not yet supported for use with Global Access sites, will not appear in the Console menu. 

Identity Access 

When Global Access is enabled for your partner, Identity Access includes a new "Data Center" column that displays the relevant flag. In addition, the user record shows the Data Center: 

 

Audit Log

Audited records are stored on the resident data center for the relevant account. 

 

Migration Guide

Existing implementations of SAP Customer Data Cloud may be migrated to global sites and site groups. Following is our best practice recommendation for doing so. 

Step 1 - Create Global Site Group

  1. Follow the instructions above and create a global site or site group to replace the existing sites. 
  2. Configure the primary and secondary data centers 
  3. Using the Configuration Copy Tool, copy the configuration of your original parent site to the new global site or parent site: 
    • Site schema
    • Policies
    • Screen-Sets

Step 2 - Migrate Userbase

Use IdentitySync to export users from local site groups. Our general guide for migrating accounts from one site to another here. Note the following: 

  • Add a step to deduplicate records based on the loginId or UID. 
  • For each account, determine and set the data residency using the dataCenter parameter. For more information, see accounts.importFullAccount
  • If the original (local) site or site group is live, set up a recurring IdentitySync dataflow that syncs any changed accounts into the new site. 

Step 3 - Update Server-Side Implementation

  1. Direct server traffic to the nearest SAP Customer Data Cloud data center. 
  2. Make sure your server-side calls are signed using an RSA bearer token. See Signing Requests to SAP Customer Data Cloud
  3. Update the server side validation of the onLogin event to use an id_token instead of a UID + signature. 

RSA bearer tokens and id_token validation are supported for local sites as well, and we recommend switching all your sites over to these methods.

 Click for a code sample of bearer token validation
private async Task<string> ValidateJWT(string idToken)
        {
            var httpClient = new HttpClient();            var response = await httpClient.GetStringAsync($"https://accounts.us1.gigya.com/accounts.getJWTPublicKey?&v2");            var jwks = new JsonWebKeySet(response);            var parameters = new TokenValidationParameters
            {
                ValidateAudience = false,
                ValidateIssuer = true,
                ValidIssuer = $"https://fidm.gigya.com/jwt/{apikey}/",
                ValidateLifetime = true,
                IssuerSigningKeys = jwks.Keys
            };            var handler = new JwtSecurityTokenHandler();            handler.InboundClaimTypeMap.Clear();            SecurityToken jwt;
            ClaimsPrincipal claimsPrincipal = handler.ValidateToken(idToken, parameters, out jwt);
            var uid = claimsPrincipal.FindFirst("sub").Value;
            return uid;
        }

Step 4 - Update Client-Side Implementation

  • When loading the Web / mobile SDKs, switch API keys to the new global site API keys (from 3_XXX to 4_XXXX)

  • CNAME needs to be switched over to a new API key (this can be done at a later stage) 

Switching API keys will effectively log off all users during cut-over.

 

Unsupported Features

Currently, some SAP Customer Data Cloud features are not supported with Global Access: 

  • Link accounts flow
  • Phone Number Login
  • Lite Accounts
  • Federation (SAML, OIDC)
  • Limited social provider support: Apple, Facebook, Google, Twitter and WeChat are supported.
  • CIAM for B2B
  • Client-side calls of accounts.search
  • Data Store
  • No labels