Site Groups and Single Sign-On

Skip to end of metadata
Go to start of metadata


Site groups are a way for clients who operate multiple sites to unite user data and behavior settings, and provide a uniform user experience across all sites that are operating under the same organization.

A site group consists of exactly one Parent site and one or more Child sites. Any unique site can only be a member of a single site-group.

As the names Parent and Child may imply, the Parent site controls the settings of all the sites in the group, including permissions, policies, data and more. The Parent site is also host for the database used by all of it's group members.

Child sites get their settings from the parent, and share the database of the parent site. Most of the settings of a child site are defined through the parent site, though some can be overridden at the child-site level.

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, his account is valid and the user is considered a registered user on all sites that are members of that group.

Single Sign-On (SSO) is a feature of site groups that automatically logs-in users to all sites in the group upon signing into one of the group sites. SSO manages a single session for a user for all group sites, so when a user is logged in to one site, he is logged in and gains immediate access to all other sites in that group, saving him the trouble of authenticating each child site individually. 

The following guide explains the various aspects and implications of implementing site groups and SSO for client who operate multiple sites.


Note: Site groups and SSO is a premium feature. If it is not yet enabled for your account, please contact your Gigya Account Manager. 


Best Practices

Group sites share not only their members, but their members' data as well. When part of a site group, a child site derives its social data from the parent site's database.

This means that all social data accumulated, such as achievements earned through Loyalty - Gamification and User Behavior, are available to use on all member sites, enabling site owners to create cross-site accounts for users, rewarding their engagement on all the different platforms.

This infrastructure calls for precise configuration in order to ensure that all aspects of the group function optimally.

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


Picking A Master

When Creating New Sites

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

 Gigya will create a new, dummy *, site 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.

 If you are in the process of building your sites and are looking to create a site group, you can create a dummy site in advance and start aggregating data from all group sites without the need to import data in the future.

 * A dummy site is a fake domain that you assign to your Gigya account (i.e., The domain will have an API key and a Gigya Database but is not a live  (active) site. It is used to configure and aggregate data for all other member sites.

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.

Recommended Best Practice is to export all user data prior to adding the site to a Site Group.

You will need to perform an import of the data to the Parent site's database in order to avoid losing the data previously aggregated.

You should consider, however, that not all data can be transported between sites, and some data loss may occur. User data will be preserved in the case of a valid login token. If a user was not logged in for a while, his login token will be expired and the data would only be available upon the user's following login. 

Read the Data Migration Section for more information. 

** The data will not really be lost, but will be inaccessible to the group members, including the site that originally controlled it.

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 acts as a link between your site and a specific social network, e.g., Twitter, so when a user registers to your website using his social identity, he grants your website permissions to retrieve information and perform actions (in accordance to the set of permissions requested) on his behalf through your app.

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 he is 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 utilizes the same application for all sites in the site group. This 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 (though they are not required to).
    Since only one app is used, new user registration will only have to be authorized once on the first site that he logs into. This contributes to transparent registration, as a user who has been authorized once will be registered and authorized on all child sites automatically.

    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 it is recommended to make sure that the social network does not advise against using one app for more than a single site.

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 Gigya Console. If you are using either the same app or multiple apps that request different permissions from the same SN you may incur failures, as the different providers treat the requested permissions differently. I.e., when using LinkedIn, the permissions checked at the Parent level are going to be requested regardless of whether the Child site's app requires them or not.

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.

Note: Users may not be aware that registering or logging into a particular site grants them access to other sites and may have reservations regarding the sharing of their data between the sites.


Migrating Data

When creating a site group out of active sites (i.e., sites that already have registered users and a social database), a data import can be performed, migrating the data from any given site into a the master database. 
Data import is performed in cooperation with your Implementation Consultant. Contact your IM to start the process.

Migration of data from several external sites into Gigya has its implications, as well as some preliminary requirements.

These requirements differ based on whether the partner is using Gigya's complete customer identity management functionality - Registration-as-a-Service, or simply using Gigya's Social login feature.

Site data is exported in a JSON file, and inserted into the destination site's database. To import data from one DB to another, the data structure of the JSON file should match the data schema of the destination site. Make sure that field values match their values in the destination schema, (e.g., a field that holds textual 'boolean' values such as 'true' or 'false', cannot be imported into a Boolean field, even though they are logically the same). 

Not all data is supported when using this method to transfer data. 

For more information on how data migration is performed, and which data fields are supported contact your IM. You can also read our import guides


The Implications of Site Groups


A site group uses a single database for all the data 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 that data which populated to its original database prior to joining the group, and all data aggregated while it was a part of the group will be unavailable.

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

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.


Data Schemas

With RaaS, every site has its own data schema:

  • Defining which data fields will be part of the Account data storage.
  • The type of each field.
  • Which fields are required and which are optional.
  • Etc.

Sites that use RaaS and are part of a the same site group must all contain an identical data schema, as all sites of a site group use the same data base (of the parent). Child sites, however, can maintain their own unique 'required' fields in addition to those required by the Parent, it is important to ensure that any fields required at child level be available in the Registration Completion screen of the group's active screen-set.

When using different schemas, users of one site may be missing required data as per another site's data schema and will be unable to use sites that do not support the required data. Users that are missing required fields will be pending registration until adding the required data. They will be prompted for the missing required fields upon their following login, in order to complete their registration.

Make sure to include any required fields in your 'Registration completion' screen, as well as in the 'Registration' screen.


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

Identity Access

If you have the Identity Access feature enabled (which happens by default when using Gigya’s RaaS and/or Identity Storage), it will be accessible from all group sites.

Data displayed on all sites will be identical and will provide an overview of the group's user base, demographics, and preferences. 

Read more in the Identity Access guide .

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.

The policies that can be altered locally at the child site level are:

  • Automated Emails - Sending automatic emails in certain situations.
  • Default Screen-sets - Note that to change the default screen sets on a member site, you must first check the 'Override' checkbox next to it.

Some policies can only be set (activated / disabled) on the master site, but can be fine tuned on each member site:

For more detailed information on Master/Child Policy settings, please see Overriding Master Configurations.


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.


All of the group's child sites share the same screen-sets. Therefore, screen-sets can only be created and edited within the Parent site's Dashboard

When navigating to a child site's settings page in the Console, you will notice that the Screen-Sets tab is gone, however, a member site can still choose its default screen-set out of the available ones from the Policies tab by checking the Override master settings checkbox.


Email Templates

By default, group sites share the same Email Templates.

However, by checking the Override master settings checkbox on the email templates page in the console, any given child site can add or change its set of email templates to be unique.


Game Mechanics

When operating Game Mechanics under 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.


Data displayed on the Reports tab in the console is only relevant to the selected website, meaning that even though the data is shared, the reports section gives unique indication on the performance of each site in the group individually. 

Single Sign-On (SSO)

SSO is only supported via client-side SDKs.

User Login

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

When a user logs into one of the member sites, a Gigya session starts for that user. When the user later loads a page of a different member site (that belongs to the same group), Gigya automatically recognizes that the second site belongs to an SSO group in which the user is already logged-in, 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 can be handled by the site admin to perform the actions necessary for a logged-in user.

Every SSO member site is advised to register to Gigya'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.

User Logout

When a user logs out from one of the member sites, Gigya needs to log the user out of all other group member sites that they are logged into, and terminate all active Gigya sessions for that user.

Make sure to complete the following steps to enable a successful SSO logout:

  1. Every member site should have a logout URL. This is a page that contains the Gigya script and issues a call to accounts.logout  /  socialize.logout  accordingly, effectively logging out the active user when the page is loaded.
  2. Send a complete list of logout URLs to your Implementation Consultant. Make sure to have a logout URL for every site.
  3. Make sure to implement user log out with a call to accounts.logout / socialize.logout to notify Gigya.

Once all is set up, Gigya will recognize when a call to accounts.logout or socialize.logout comes from a site that belongs to an SSO group. In such cases, Gigya will call the logout URL of each member site that as an active session (user is logged into), as a result logging the user out of all SSO group sites.

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

Browser Restrictions

The SSO feature relies on 3rd party cookies (3pc). In some browsers, 3pc is disabled by default (e.g., Safari), meaning that SSO will not work for users using those browsers.

Users who block third party cookies will need to log in as well. For a potential workaround, see  Supporting SSO on Browsers That Block Third-Party Cookies.

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 into a 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 site.
  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 into a site that does require that field, the user will be required to complete the registration process and fill in any required information.

How it Appears on the Console

When logging into the console, you will see a list of the sites associated with your partner ID. 
Site groups have the group icon next to them. Master sites are marked with the purple icon   , member sites are marked with the blue icon   .

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

For each group, the master site will appear first, followed by its member sites. 

SSO sites have a  icon next to their name.