Name: Explaining Site Groups and Single Sign-On in SAP Customer Data Cloud
Uploaded: 2024-4-24
Duration: 483 s
Description: In this video we’ll discuss site groups and single sign-on options for SAP Customer Data Cloud. We’ll also cover Global access and single sign-on, referred to as SSO and SSO segments. Moreover, we will discuss SSO with Browser Tracking Prevention and the best practices for creating a site group.

Share feedback

<p>Planned maintenance of Practice Systems</p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Subscribe now

Learn more

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div>In this video we’ll discuss site groups and single sign-on options for SAP Customer Data Cloud.  We’ll also cover Global access and single sign-on, referred to as SSO and SSO segments. Moreover, we will discuss SSO with Browser Tracking Prevention and the best practices for creating a site group. </div></div></div>

Explaining Site Groups and Single Sign-On in SAP Customer Data Cloud

Hello, and welcome to this video  of Site Groups and Single Sign-on  in the SAP Customer Data Cloud.   In this video, we’ll discuss site groups and single sign-on options  for SAP Customer Data Cloud.   We will start with understanding site groups  and their purpose.   Then, we’ll cover Global access  and single sign-on, referred to as SSO and SSO segments.   We’ll also discuss SSO with Browser Tracking Prevention  and the best practices for creating a site group.  Finally, we’ll see a demo of the configuration.   Site groups are used when you own multiple sites and wish to have a unified database of all users  and a centralized place for setting site configurations.  A cycle consists of one parent site  and one or more child sites.   This means a user has only one profile shared across all sites in that group.   All members of a site group must have an identical data schema.   If the field is required at the parent level,  it’s also needed on the child sites.   If you must have different required fields,  set those fields to not required on the parent  and make them required on the child.   It’s important to mention that if a field is required at the parent level  and the field is not available to the child, the user will be unable to complete the registration with the parent-child relationship  Any setting and policy are created at the parent level.  This includes permissions, policies, and more.  Child sites can override certain settings as well.   SAP Customer Data Cloud stores user data  in four data centers:  the US, Europe, Australia, and China.   Global Access allows you to create a site or group  that belongs to more than one data center.  So, you can provide a consistent user experience regardless of the users' physical location.   Previously, users had to register separately for each of the regional sites.  When moving around the world with global access,  users can log into your localized sites with their existing accounts.   User data is stored in the data center  they use to create their account.   So, you can comply with various data residency regulations before global access site groups can exist on one data center.   Single sign-on, or SSO, allows a user  to be seamlessly signed into one side after signing into another.   You define the sites that belong to the same SSO segment.   Once a user logs into one of those sites in the segment,  the user's login state is synced across  all sites in that segment.   When users log into Site A,  they are simultaneously logged into Site B  as long as the site belongs to the same segment. The same goes for logging out of SSO segments,  which saves users the effort of authenticating  separately to each site.   In this example, we'll see how site groups work.  Sites 1 through 6 are in the same site group.  That means that they have a single database of users.  If a user registers in any of the sites of that group,  this user will also exist for the rest of the sites.  Sites 1 through 3 would be part of the same SSO segment  and share the SSO logged-in state.   This means if a user logs into Site 2 and navigates to Site 1 or 3,  this user will automatically be logged in.  SAP Customer Data Cloud automatically recognizes that the second site belongs to the same SSO segment  and fires an onLogin Event sent to the second site.   The onLogin event should be handled  to perform the actions necessary for a logged-in user.   The same goes for logging out.   The 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 CDC sessions and all the sites that belong to that segment. Sites 4 through 6 are in another SSO segment but within the same site group.  They share the same user base  as sites 1, 2, and 3 but require separate authentication.  To be clear, let's take the example of Site 2.  The user logged into Site 2 would not be automatically logged into sites 4, 5, or 6. Note: Site 7 is a standalone site,  meaning it does not share its users with the other sites  and is stored in a completely separate database.  Some browsers include Tracking Prevention features  designed to block ads but may also prevent SSO from working.   To overcome this issue  and allow a single login experience to all sites in the group,  we recommend setting up a centralized login domain  to which all sites will redirect their login requests.   With this setup, SAP Customer Data Cloud  recognizes that users logging into this domain belong to the sites in the group  and keeps them logged in when they navigate to another site.   As an implementation best practice, we recommend 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  and will act as the parent site in your group.   This site will contain all the user data,  the group’s settings, and policies.   First, create the parent site. Then, the child sites.  Be sure to indicate which is the parent and which are the children.  Create groups before any configuration or development commences.   Note that parent sites and data centers  cannot be changed later.   For single sign-on, do the same with site groups and define logout URLs  for each child site.   Make sure to indicate which site  the logout URLs are for.  These logout URLs will trigger a logout on the client side.  If you wish to create a site group of sites  from different data centers,  remember to define those sites as “global”.  Let's briefly tour site groups and single sign-on  in the Customer Data Cloud console.  In the site tab, you can see the parent site, demo.parent.com,  and one child site, demo.child1.com.  At present, there is only one site in the site group.  Each site has its own generated API key.  In our case, the child site demo.child1.com  inherits all settings and policies from its parent site.   The child can override some settings.   Now, we’re going to create another child site named demo.child2.com.   Choose the three dots for the Parent under Actions  and select “Create Child Site”.   After filling out all the necessary fields,   the child site has been created successfully.   To find the site group functionality,  navigate to the “Advanced” tab  on the left-hand menu  and choose Site Groups.  Select your site group.   To have the SSO option, check “SSO enabled”.   If both child sites are within the same segment  and SSO is checked by logging into one child site,  users don't need to enter their credentials again  to access the second site.  They are automatically logged in.   Let's see what happens when SSO is enabled,   but we have different SSO segments.   Create one more child site  and call it demo.child3.com.   Put the third site in a different SSO segment  by expanding the site and entering a new SSO Segment name  into the field.   When a user logs into Site 1,  he will be automatically signed into Site 2,  but not Site 3. This concludes our video explaining Site Groups and Single Sign-on.  Thanks for watching.