- SAP Managed Tags:
Several improvements have been released recently to the certificate provisioning process, and I'll give an overview of these changes and how they affect your implementations. Firstly, what is certificate provisioning and when would you use it?
Generally, you use an SSL certificate to prove to your users that their connection to your site is secure, and that you are who you claim to be, the legitimate owner of the domain. To users, this appears as an "https" connection, signed by a trusted issuer. When you use a third party provider on your apps or websites, such as SAP Customer Data Cloud (Gigya), you may prefer to load our services via your own server, for the following reasons:
The SAP Customer Data Cloud provisioning process is essentially a process of proving domain ownership, and setting up a trusted exchange between your servers and ours, so that from the client’s perspective, the interaction is only with your servers, while behind the scenes you are loading and calling SAP Customer Data Cloud.
So what are the improvements to the process for provisioning your certificate on Customer Data Cloud? Well, these fall under "self service":
In addition, we've released the backend support for SSO using the centralized login domain approach. This architectural concept means that users of all sites in your site group who wish to login to each respective site, are all redirected to the same page for performing the login. After they log in you can redirect them back to the source site, and they can continue to happily browse between the different sites of the group as a logged in user. To set up a centralized login domain, you need to provision your domain via the SAP Customer Data Cloud provisioning flow.
Want to find out more? Visit our documentation –
Generally, you use an SSL certificate to prove to your users that their connection to your site is secure, and that you are who you claim to be, the legitimate owner of the domain. To users, this appears as an "https" connection, signed by a trusted issuer. When you use a third party provider on your apps or websites, such as SAP Customer Data Cloud (Gigya), you may prefer to load our services via your own server, for the following reasons:
- Your customers know and trust you, but not the "gigya" domain. Redirecting users to an unknown URL (e.g. gigya.com) may raise their suspicion. Using certificate provisioning allows you to load the Gigya services from your own domains for a smooth user experience.
- Some browsers and browser settings may block redirects to a third party, meaning SAP Customer Data Cloud flows will be blocked. Serving SAP Customer Data Cloud from your own domain prevents this.
- Recent browser tracking measures introduced to Safari and Firefox completely block a single sign-on (SSO) experience if you do not log all users in from your own domain. This can be overcome using a centralized login domain, which also requires provisioning your SSL certificate as part of the setup process.
The SAP Customer Data Cloud provisioning process is essentially a process of proving domain ownership, and setting up a trusted exchange between your servers and ours, so that from the client’s perspective, the interaction is only with your servers, while behind the scenes you are loading and calling SAP Customer Data Cloud.
So what are the improvements to the process for provisioning your certificate on Customer Data Cloud? Well, these fall under "self service":
- We've listened to customers for whom domain email validation was not a scalable option and added DNS domain validation.
- You can now define your API domain prefix in a field on the Site Settings page in the Console, where once you needed to open a support ticket to have SAP Customer Data Cloud support do this on your behalf.
In addition, we've released the backend support for SSO using the centralized login domain approach. This architectural concept means that users of all sites in your site group who wish to login to each respective site, are all redirected to the same page for performing the login. After they log in you can redirect them back to the source site, and they can continue to happily browse between the different sites of the group as a logged in user. To set up a centralized login domain, you need to provision your domain via the SAP Customer Data Cloud provisioning flow.
Want to find out more? Visit our documentation –
