SAP Customer Data Cloud Positions

Site Groups and Single Sign-On

Skip to end of metadata
Go to start of metadata


Site Groups are used when you own multiple sites and wish to provide your users with a different experience in each site, but to have a unified database of all users and a centralized place for settings configuration. Within a site group, users are shared across all sites in the group along with their user data. Once a user registers to a member site of a site group, their account is valid and the user is considered a registered user on all sites that are members of that group.

  • A site group consists of one Parent site and one or more Child sites. Each site is associated with a SAP Customer Data Cloud API key. 
  • All sites in the group share the same user database, hosted on the Parent site, so that a user's data is available to all member sites.
  • Any unique site can only be a member of one site-group. 
  • All the sites within a given group share the same data center. 
  • Child sites inherit most of their settings from the Parent, including permissions, policies, and more.  

Single Sign-On (SSO) allows a user to be seamlessly signed in to one site after signing in to another. Within a site group, you can define a sub-group of sites, known as SSO Segments, which share an SSO experience. SSO manages a single session for a user for all the sites in the segment, so that when a user is logged in to one site, and they visit another site in the group, they are logged in, saving them the trouble of authenticating separately to each site in the segment. A site can belong to a single segment only. 

Note that Single Sign-On is not supported on anonymous browsers.

Since August 2019, SSO between different domains does not work on Safari and Firefox browsers, due to tracking prevention features that target adtech. These browser changes impact SSO capabilities offered by many CIAM vendors, including SAP Customer Data Cloud. To implement SSO in these situations, see SSO with Browser Tracking Prevention.


Watch an Instructional Video

If you have an SAP logon, you can watch an instructional video about Site Groups and Single Sign-On here.

Site Groups - Best Practices

The following section describes the best practices for creating a site group.

Selecting a Parent

When Creating New Sites

As a best practice implementation, it is recommended not to use an existing working site as a Parent.

You should create a new dummy site within the data center that will be used by this site group, that will act as the Parent site in your group. This site will aggregate all the user data and concentrate the group's settings and policies.

 * A dummy site is a domain that you own, but is not a live site accessed by your users. After adding the site to your Gigya account,  the dummy will have a Gigya API key and database.

When Grouping Active Sites

If you are creating a site group out of currently active sites, or adding active websites that already contain user data to a site group, the data on the added site will be lost unless imported. In any case, audit log and consent vault entries are lost for the exported site. For more information on importing accounts from one site to another, see IdentitySync.

Following a data transport, a user session will be preserved in the case of a valid login token. If a user was not logged in for a while, their login token will be expired until their subsequent login. 

Recommended Best Practice is to configure your site group members in advance when possible, and avoid removing or adding sites to an active site group, and in particular, adding active sites.

Social Network Apps

Every site that performs social actions, e.g., login with Facebook, needs to have a social network app (SNAPP) associated with it.

Your SNAPP is a link between your site and a specific social network, so when a user registers to your website using their social identity, they grant your website permissions to retrieve information and perform actions on their behalf.

There are two approaches to maintaining social network apps in a site group. Each approach has its pros and cons, it's up to you to decide which suits you better.

  • Defining a unique app for each child site - This approach maximizes flexibility when regarding social permissions. Each site can define its own set of permissions, retrieving different data and performing different actions.

    Since each app has its own unique set of permissions, user authorization will be required for each site individually when accessing a site for the first time.

    Also note that with this approach, adding a connection will only affect the user's connections on the site they are currently logged into, and will not be reflected on other member sites, whereas with a single app on an SSO group, adding a connection will also change the user's state on all member sites.

    * When using multiple apps with Facebook for a site group, it is required to keep all apps using the  same Facebook API version . You are also required to configure a business entity for your sites, to aggregate and transfer data across all sites in the group easily.

  • Defining a single app for the group - This approach maximizes control over app settings and reduces app maintenance, since only one app is maintained. With a single app, all sites share the same permissions, and are able to retrieve the same data and perform the same actions. Since only one app is used, new users will only have to be authorized once, on the first site that they log in to. This contributes to transparent registration, as a user who has been authorized once will be authenticated automatically in all sites in the group.

    Important: Make sure to have all your sites require the same permission set when more than one site within the group use an app on any particular social network.

It is important to note that some social networks advise against using a single app on more than one site categorically. For this reason, when defining SNAPPs, research the requirements of the social networks you intend to use. Among the leading social networks (Facebook, Google+, Twitter and Linkedin), Facebook is the only one that advises against sharing an app on multiple sites.

When Setting up the permissions within your Site Group, it is important to ensure that all the sites within the group use the same permissions set and that these permissions are defined and configured correctly within the Parent and Child Permissions pages of the Console.

Internal Note: The permissions system is being changed in the re-design to address the above issue, so that in the future permissions will be able to be set at the Child site level independently of the Parent and vice versa.



To create Site Groups:

  1. Open the Site Groups tab, in the Admin tab of the SAP Customer Data Cloud Console.
  2. Click Create Site Group.
  3. In the Create Site Group window: 

    1. Select the Parent site from the dropdown.
    2. Enter a relevant description for this site group.
    3. If sites in the groups share an SSO experience, check SSO enabled. See below for more information on configuring SSO Segments.
    4. Click the Add Sites button to select the sites which will be added. Only partner sites that share this data center, and that are not assigned to a different site group, will be displayed.
    5. Click Create.

How it Appears on the Console

On the Sites page of the Console there is a list of the sites associated with your partner ID. 
Site groups are visually grouped together. The master site has a collapse / expand control next to its name: 

All sites under that node, are its child sites. 

The site groups will appear first in the console, followed by the individual sites (i.e., not members of any group).

In addition, a Collapse All or Expand All control is available on the top right corner of the site list, for collapsing or expanding all site groups, for your convenience.


Implications of Site Groups

Adding and Removing Sites

A site group uses a single database for all the users aggregated from multiple child sites. This database is associated with the parent site, although all child sites can access it and contribute to it. When a site is removed from a group, it is also denied access to the group's database and becomes a standalone regular site. If this site was previously active before joining the current site group, it will revert to using its original database.

The site will only have access to the data collected in its original database, prior to joining the group. All data aggregated while it was a part of the group will be unavailable to that site.

If the site was not active before, it will have no data.

Data Schema

Sites that are part of the same site group must all contain an identical data schema, as all sites of a site group use the same data base.

Child sites can maintain their own unique 'required' fields apart from those of the parent. When using different schema field requirements, users of one site may be missing required data as per another site's data schema. Users that are missing required fields will be pending registration on any site that requires those fields until adding the required data. Therefore, it's important to ensure that any fields required at child level are available in the Registration Completion screen of the group's active screen-set. Users who are registered with one site, but missing required information for another, will be prompted to provide the missing required data once they log in to the second site, via the Registration Completion screen.


If a field is required at the Parent level and the field is not available on the child, the user will be unable to complete their registration.

Identity Access

Identity Access is accessible from all sites in the group. Data is displayed identically on all sites and provides an overview of the group's user base, demographics, and preferences. 

Site Policies

 Most site policies are set on the Parent site and affect the entire group.

The Policies page on child sites will show the current site policy settings but will not enable the user to edit them, with the exception of a selected few.

To override master configurations for a child site:
  1. Go to the Policies page for the relevant child site. 
  2. Check the Override master settings checkbox for the relevant configurations (e.g., Additional Security Measures).
  3. Click Save Settings.

These are the only settings that can be overridden by a child site: 

  • Default login and registration screen-sets
  • Email verification
  • CAPTCHA requirement for new registrations
  • The sending of the following automated emails: 
    • New user welcome
    • Password reset confirmation
    • Account deletion confirmation

Some policies can only be activated or disabled on the master site, but can be fine-tuned on each member site.

For information on overriding policies in a child site when using the REST API, see Overriding Master Configurations.

Member Site Policy Override

When overriding policy for individual member site in a site group configuration, it is important to bear a number of items in mind:

  1. When overriding email verification policy in individual member sites, if a user first registers to a site that does not require email verification and then subsequently navigates to a member site that does, the user will be required to complete the email verification process for the second site, even though they were not required to do so with the first.
  2. When required fields are overridden by a member site, if a user first registers to a site that does not require a particular field and then subsequently navigates to a site that does require that field, the user will be required to complete the registration process and fill in any required information. In this case, make sure the required field is included in the Registration Completion screen.


Permissions can be unique per site or shared among all sites, depending on the number of SNAPPs defined in the group, however, it is important to make sure that when using a single app for multiple websites, Permissions for all sites must be identical and defined at both the Parent and Child level.

For more information read the Social Network Apps section.


By default, all of a group's child sites share the parent's screen-sets.

Use Custom Screen-Sets For A Child

To use unique screen-sets for a child site, open the Screen-Sets page of the Console.

If the child does not yet have any screen-sets, the page will show an empty screen-sets section for the child, and show the parent site's screens:

You can now either Duplicate an existing screen-set from the parent to customize, or to begin to use a unique screen-set, you can add a new collection to the site using the Add New Collection button.

When duplicating screen-sets, it is recommended to change the name - if both child and parent have screen-sets of the same name, the child screen-set always overrides the parent's.

For more information on working with screen-sets, see: 

Before deploying your screen-sets, you have to enable the Override master settings option in the site's Policies and select the appropriate RegistrationLogin screen-set from the available drop-down menus.


If both a child and parent have a screen-set with the same name, when calling accounts.showScreenSet from the child's API key, the child's screen-set will always be the one displayed.

Email Templates

By default, group sites share the same Email TemplatesBy checking the Override master settings checkbox on the email templates page in the console, a child site can use their own set of templates.


This feature or component is being deprecated and will cease to function on January 31, 2021. For more information, see Social Engagement Deprecation.

When operating Loyalty (GM) in a site group, user engagement is rewarded through your entire platform and across all sites.

This means that although Challenges are unique for each site in the group, users' earnings (i.e., points and actions completed) are aggregated per user and shared across all sites in the group.

This way, a user is being awarded for his contribution on the entire platform, and not only on a single site, while at the same time allowing each site to maintain an individual character and provide different challenges and different rewards for different actions.

Integration Overview 

If an action is defined at the Child level and that action is used in a challenge that is defined at the Parent level, the points will roll up to the Parent.

Challenges that are created at the Parent level are available to all Children.

Actions that are created at the Child level are available at the Parent level as virtual actions, i.e., the Parent can not edit the action but can use it in other challenges.

A Child can not see another Child's actions.

  • If a challenge created at the Parent utilizes virtual actions from Child A, Child B will have access to the challenge but not that action (from Child A).

An action that exists on a Child will always override a Parent action of the same name.

Child Actions override Parent Actions with the same name Even If The Child Action Is Disabled!

This is especially important regarding the Gigya _default Challenge which exists on all sites. If your SSO Group utilizes Gigya Default Actions, these Actions MUST be configured at the individual Child Level. See Loyalty Configuration and Administration - Exporting GM Settings for how to streamline the configuration process.

Recommended Best Practice is to always create uniquely named Challenges and Actions at the Parent level for use throughout the SSO group, if all children will use these same settings.

The Group Custom User Actions table on the Actions page of the Gigya Console will not appear on Child sites.

Points accumulated for a challenge created at the Parent level will be available to all Children, even if the points were generated by another Child.

  • Actions to be shared among multiple Children should be created at the Parent level and all Children will be able to call gm.notifyAction on those actions.


The Reports tab in the Console displays data for the selected site only. Even though data is shared between sites, the reports differentiate between sites and display only relevant data.

WebSDK Configuration Object in Site Group Scenarios

When working with site groups, the web SDK configuration of the parent is inherited by the child sites. If you define values for the same parameters in the configuration object of both the parent and the child, the configuration for the child will override those of the parent. However, you may write custom code to have the settings of the child site appended to those of the parent, rather than override them. 

For example, parent site A has only Facebook listed under enabled social providers: 

    enabledProviders: ['facebook']

This is the configuration for child site B: 

    enabledProviders: ['twitter']

In this case, a user of child site B that wishes to log in with a social network, will be offered only Twitter as an option. To append Twitter to the existing setting (Facebook) rather than override it, the child site configuration would be: 

    enabledProviders: (siteGroupGlobalConf.enabledProviders || []).concat(['twitter'])

Now the user of child site B will be offered both Facebook and Twitter as social login options. 

Single Sign-On (SSO)

SSO is only supported via client-side SDKs and is not supported on anonymous browsers.

SSO with Browser Tracking Prevention

Recently, Apple has decided to completely block 3rd party cookies for its Safari browser. This has major effects on all CIAM providers regarding session management solutions. SAP Customer Data Cloud is working on building a satisfactory, long-term solution to enable support for our session and sign-on features on Safari. 


Dynamic sessions (setting a sessionExpiration to -1, as explained here), is not supported on Safari.


Single Sign-On

To enable single sign-on for all browsers, you must create a central login page on your site, and redirect logins from all sites in the group for which to enable SSO, to that page. For example, a site group consists of sites A and B. A user visits site A, and clicks "login". They are redirected to the central login page, where they log in as usual. After successfully logging in, they are automatically redirected back to site A. Then, when they visit site B:

  • If the user is on a browser with tracking prevention, they are not logged in automatically. They click "login"and are redirected to the central login page, that recognizes they have an active session, and redirects them back to site B. 
  • If the user is on a browser without tracking prevention, the Gigya SDK recognized their session and they are automatically logged in to site B.

All domains that participate in the redirect flow (the site domains, the central login page etc) must undergo a process of Certificate Provisioning.


To enable single sign-on (SSO) in site groups, that will work on browsers that include browser tracking prevention, do the following:

Central Login Page

On your site group, create a page to which all sites of the group redirect, for login purposes. Set this page up to include the Gigya login functionality (e.g., load the Web SDK and relevant login and registration screen-sets). We recommend the following: 

  • The site on which to implement the login page, should have the least restrictive policies (e.g. required fields, Risk Based Authentication definitions). 
  • This would usually be the parent site of the site group. 



In the WebSDK Configuration on the parent site, make sure to set a storageDomainOverride for the site on which the central login domain is set up. The domain should be a concatenation of the custom API domain prefix with your site domain. For example, if the prefix is "login" and your domain is "", the storageDomainOverride should be set to "".

Site Group Setup

  1. Open the Admin menu in the Console.
  2. In the left menu, select Site Groups.
  3. On the row for the relevant site group for which you wish to enable SSO, under Actions, select Edit .
  4. Make sure SSO enabled is checked.
  5. Add the Central Login Page URL.

    - SSO Segments are currently not supported.

    - When adding the Central Login Page, it is automatically added to the list of trusted sites in the Site Settings page for all the child sites of the group, so as to pass the validations applied by Gigya during the redirect process (since the login call originates from the Central Login Page URL and not the child site URL).


  1. On the site page on which to enable login, load the SAP Customer Data Cloud Web SDK.
  2. Set the login button to call the following method: 

                authFlow: 'redirect',
    			redirectURL: '',
                context: {
                    myCustomLang: 'ar',
                    myCustomSessionExpiration: 60 * 60 * 24 * 3

    Note the following: 

    • The redirectURL, authFlow and context parameters are not mandatory. 
    • redirectURL: the page to which the user is redirected, after they complete a successful login on the Central Login Page. If none is specified, the user will be redirected to the page from which the login originated. 

      Any URLs to which the user is redirected, must be included in the list of Trusted Site URLs in your Site Settings.

    • context: can include any context that will be carried on to the Central Login Page and handled there by your code. For example, it may be used to customize the user experience, by passing the relevant language. The same context is also included after the user completes login, in the onLogin event.
    • authFlow: can be 'redirect' or 'popup' (the default value). If you choose popup, the login or registration screen will appear as a popup on the same page from which the login was triggered. If you choose redirect, the user is redirected to the central login page to log in, and after logging in, redirected back based on the value of redirectURL.
  3. Repeat for all login pages in the site group for which you wish to enable an SSO experience.
  4. On the Central Login Page: 
    • Load the SAP Customer Data Cloud Web SDK on the Central Login Page.

    • To ensure that logged in users will be automatically redirected, add the following code: 

      gigya.hasSession().then(function(sessionExist) {
      	if(sessionExist) {
      	} else {
          	 onLogin: function() {
    • To customize the login experience on the central page, you can read the context from the query string parameters and implement some code around it. The context is parsed automatically, so you may read it by using getUrlParam, as follows: 

    • Log the user in using Screen-Sets or other authentication methods. 
  5. After the user successfully logs in, they are redirected back to the site from which the login originated (unless a redirectURL was specified). If the user is missing any required fields, the Profile Completion screen will be displayed for the user to complete their registration. Make sure all relevant screens have the required fields displayed. For more information, see Advanced Registration Flow

Using the above architecture, where the login process includes 2 separate API keys, there will be 2 separate onLogin events fired once the user completes the login: one for each API key.




User Login


Single Sign-On is a means of authenticating users and managing their login sessions between applications and websites. After an SSO connection is established between apps, users need only authenticate to one of the websites or apps to be automatically authenticated and logged in to the other. SAP Customer Data Cloud offers an out-of-the-box option for connecting child sites of a site group to SSO Segments

When a user logs into one of the member sites of a segment, a SAP Customer Data Cloud session starts for that user. When the user later loads a page of a different member site (that belongs to the same segment), SAP Customer Data Cloud automatically recognizes that the second site belongs to the same SSO segment, and fires an onLogin event, which is sent to the second site. The user is automatically logged into the second site, and the onLogin event should be handled to perform the actions necessary for a logged-in user.

Every SSO member site is advised to register to SAP Customer Data Cloud's onLogin event (using socialize.addEventHandlers or accounts.addEventHandlers).

Note: The onLogin event will not include a context object if the login was triggered by another site.

Unable to render {include} The included page could not be found.

User Logout

When a user logs out from one of the member sites, SAP Customer Data Cloud logs the user out of all other sites in the relevant segment, and fires an onLogout event, that terminates that user's active SAP Customer Data Cloud sessions in sites that belong to the segment.

To configure SSO successfully, create a logout URL for every member site in the group. This is a page that contains the SAP Customer Data Cloud script and issues a call to accounts.logout  /  socialize.logout  accordingly, effectively logging out the active user when the page is loaded. A logout URL must be public facing and not behind a firewall (even in a development environment) so that SAP Customer Data Cloud APIs can access it. 

Once all is set up, SAP Customer Data Cloud will recognize when a call to accounts.logout or socialize.logout comes from a site that belongs to an SSO segment, and will call the logout URL of each visited member site of the segment, thus logging the user out of all SSO group sites.

Keep in mind that this process only terminates SAP Customer Data Cloud sessions. If you manage site sessions independently, you will need to terminate those sessions explicitly, as SAP Customer Data Cloud cannot terminate your site session for you.

When calling accounts.logout in an SSO group, it is important to note that the callback initiates when the response is received to the current site. This means that it is possible that the logout event has not completed on all other child sites. If you require that the user is logged out from all child sites prior to initiating the callback (i.e., when redirecting the user), you must set a timeout inside the callback of accounts.logout.



For information on managing sessions, see Managing Session Expiration.


Assign SSO Segments

To configure the sites of the SSO group:

  1. In the Site Groups page, in the Admin tab of Gigya's Console, click the Parent Site ID or the Edit Site Group icon.
  2. Make sure the SSO enabled box is checked.
  3. All sites in the group are assigned to the DEFAULT SSO Segment initially. To assign them to a different segment, click the value under SSO Segment and type the name of the relevant segment. For example, assign the first three sites in the group a segment of "1" to group them into one segment, and the next two sites the segment "2" to group them into a separate segment.
  4. Add the relevant Logout URLs.
  5. Save changes.




The license could not be verified: License Certificate has expired!