CRM and CX Blogs by SAP
Stay up-to-date on the latest developments and product news about intelligent customer experience and CRM technologies through blog posts from SAP experts.
Showing results for 
Search instead for 
Did you mean: 
Let's take a look at the CDC Hosted Pages and explore how they can simplify implementation of Central Login Pages and enablement of Single Sign-On (SSO) between sites.

Hosted Pages allow hosting of your own pages on the CDC server. Not any pages though. The pages are intended to implement the CDC flows by exposing the corresponding screen-sets. Hosted Pages are created with a reference to predefined templates including Login, Profile Update and Reset Password. The Login template supports implementation of SSO based on WebSDK, SAML or OIDC. The pages offer some level of customisation like CSS styling, header and footer toolbars, Google Analytics tracking, flow -specific settings (e.g. redirect URI to the login page for the Profile Update template for not logged in users).

There is a number of benefits that comes with this feature. Some of the benefits result from the fact that the pages are hosted outside of your organisation. This allows for offloading your own infrastructure and benefitting from the scalability and high availability offered by the CDC platform. This, in turn, reduces your operating cost e.g. by eliminating the need to manage excess processing power only to sustain peak loads. In addition, Hosted Pages are implemented centrally and can be used across different touchpoints. This reduces the initial implementation effort, allows for rapid deployment of changes across the channels and simplifies onboarding of new applications. The centralised approach also results in a consistent UX offered throughout the touchpoints. All this can significantly reduce the time to market.

Any flaws? Yes, you might need to compromise on the UX since you can't fully customise the pages and you need to use the screen-sets. However, this trade-off seems to be justified given all you get in return.

One of the main use cases supported by Hosted Pages is setup of a Central Login Page and enablement of SSO. To illustrate how this use case can be implemented in CDC we'll follow our favourite company - Double-Y (DY). DY owns two brands - Yin and Yang. Both brands have their own sites hosted on separate subdomains of the DY's domain. DY want to integrate both brands with CDC, implement a Central Login Page with a help of Hosted Pages and offer SSO between the brand sites i.e. if a user logs into a site of one of the brands she can seamlessly access the other one. DY decided to enable the SSO based on the CDC WebSDK but both SAML and OIDC are possible too. To further leverage on the CDC hosting capabilities, DY will also implement a hosted Profile Update page.

This task can be broken down into the following steps:
(1) Set up the sites
(2) Prepare the screen-sets
(3) Create the hosted pages
(4) Set the Central Login Page and enable the SSO
(5) Adjust the web sites

The diagram below outlines how the main building blocks fit together.

(1) Set up the sites

First things first, let's set up the site structure in CDC. It will consist of a single site group pointing to the DY domain and two child sites mirroring the DY's brand sites.


We'll omit the details of the sites configuration (policies, security, desired identity verification etc.) since this is not directly related to the Hosted Pages but, obviously, in real circumstance you'd need to take care of this.

However, the two following items are relevant for us:

  • Setting up the SSL certificate

    • To publish Hosted Pages we need to create a DNS CNAME record which links our domain with the CDC domain (note: this is not required to generate a Development URL for a hosted page)

    • You'll also need to create additional DNS CNAME records required for validation of the domain ownership

    • This process is supported by the Advanced->Certificate Provisioning option in the console which will guide you through the required steps

    • At the end of the process you'll be prompted to maintain the Custom Domain API Prefix

    • Refer to Help for more details

  • WebSDK Configuration

    • We need to add the parameter storageDomainOverride to the parent site's global configuration (console: Advanced->Web SDK Configuration)

    • The new entry should look in the following way: storageDomainOverride: '<Your Custom Domain API Prefix>.<Your Domain>.com',

    • Refer to Help for more details

(2) Prepare the screen-sets

We only need to enable a single set of screen-sets on the parent site level. Since we want to host both the login/ registration and profile update flows we'll need the two collections:

  • RegistrationLogin

  • ProfileUpdate

We'll use both collections as-is but, normally, you'd like to tune the screens according to your requirements.

(3) Create the hosted pages

The time is finally ripe to set up our Hosted Pages. This can be done so quickly that it seems completely uneventful and I wouldn't even mention it if it wasn't the main topic of this blog!

  • Console: User Interfacing->Hosted Pages, Create New Page

  • Add the page name and the path (e.g. login, update)

  • Choose the type:

    • Login: for the login and registration flow

    • Reset Password: for the password reset flow

    • Profile Update: for the profile update

    • Generic: for anything else (e.g. Lite registration)

  • Add references to the screen-sets created in the previous step

  • For the update page, add link to the login page (Login URI); this will re-direct not logged in users to the login page

  • Enable Google Analytics tracking if required

  • Amend the layout (CSS, footers, headers) of the page as per your requirements

  • Publish and test the Production URLs

  • Refer to Help for more details

As a result we have two fully functional pages hosted on CDC and accessible from within our domain: login and update.

(4) Set the Central Login Page and enable SSO

Let's set our login hosted page as the Central Login Page for our site group and enable it for SSO (Console: Advanced->Site Groups).

(5) Adjust the web sites

Finally, we need to adjust our DY brand sites to implement login, profile update and logout.

The following steps need to be repeated for pages of both brands:

  • Load the CDC Web SDK by adding a reference to the gigya.js script file. Make sure you point to the correct CDC brand site (API key).

  • Login handling

    • Invoke gigya.sso.login on Login link/ button click

    • Use the code below for reference

    • gigya.sso.login(
      authFlow: 'redirect',
      context: {​​​​​​​​
      myCustomLang: 'ar',
      myCustomSessionExpiration: 60 * 60 * 24 * 3

  • Profile Update handling

    • Set the Profile Update link destination to your Profile Update Hosted Page

  • Logout handling

    • Invoke accounts.logout JS

Well, that's it. With these five straightforward steps DY integrated both brand sites with CDC, enabled SSO and implemented centralised Login and Profile Update pages based on Hosted Pages. However, there is still something missing here. What if you'd like to have different variants of the page (e.g. brand specific variants) and display a particular variant depending on the site you're navigating from? Stay tuned. This is coming soon...

0 Kudos
Hello Mariusz,

Good post! Is this hosted page can be applied for login to access network and WIFI ? I could not find SAP resources explains for this use case, but thought the WIFI network should be handled by CDC as well, as the other CIAM solution offers this type of workflows.

So would it be possible to implement a central login page (similar feature like captive portal from a hotel's WIFI) to force a user to authenticate before connecting to the internet from our corporate WIFI network? We'd like to create the CDC flow to intercept the attempted connections and redirect the user to the CDC hosted web page. After the user completes the registration including consent information, their connections are no longer redirected and they are allowed access to the internet.

Thanks and kind regards,

0 Kudos

Hi Thahir, I see no reasons why this setup wouldn't work for you case. In principle, CDC could act as an Identity Provider for any application. Hope this helps!