On Thursday 6th of February 2020, we presented the latest Customer Data Cloud Webinar with a focus on how to take advantage of new browser security processes. The presenters of the session were:
In the webinar, we discussed how Customer Data Cloud can be leveraged to protect user data using security rules, and to take advantage of SSO capability while ensuring transparency and meeting data privacy agreement.
If you were not able to attend the live session, you can find a link to the recording here.
Ratul and Fred discussed the importance of data privacy, described Customer Data Cloud functionality available to ensure that data and applications are accessed by trusted users, and finally highlighted how WebKit Tracking Prevention Policy is designed to prevent cross-site tracking in order to provide full control to the end user and avoid any miss-use of data by third party applications.
This blog post will explain how to strengthen security by defining a password policy and Risk Based Authentication rules, and implement SSO considering new browser security processes. During this webinar, we used the Webinar demo site created in a previous Webinar in August 2019.
First, it is important to note that Customer Data Cloud securely stores passwords in their hashed form in order to avoid exposure of plain text passwords. However, hiding plain text passwords is not sufficient to protect user data. It is therefore critical to have the ability to define password policy as well as authentication security measures.
Customer Data Cloud allows password policy to be configured easily from the Console. In the event that the end-user application implements screensets then the forms (registration, password change) will react accordingly without any further changes.
The below parameters are available:
These parameters can be found in the Settings section under Policies in the Console, as per the below screenshot.
Risk Based Authentication provides the ability to create rules which trigger Actions (IP/Account lock, Captcha, TFA) based on events (Failed logins, IP/Device/Country change).
There are 2 types of rule:
When building a rule, you need to define 2 sections:
These rules can be created from the Console under the RBA section:
CAPTCHA is designed to ensure the authentication is not performed by a robot. In the event Captcha is triggered during the login, the end user will need to run through the Captcha process (i.e. click "I'm not a robot" and/or select the appropriate pictures) in order to complete authentication.
Note that only reCaptcha v2 is currently supported during login. Also note that invisible reCaptcha is available for registration, however this does not require a RBA rule.
TFA is an additional verification method which relies on the ownership of a registered email, mobile phone number or mobile device in order to complete authentication.
When creating a rule for TFA, you will need to provide the minimum level required in order to complete the validation:
These different options can also be setup from within the Customer Data Cloud Console, as per the below screenshot:
In the example below, we will imagine that we are working with a customer who is managing food catering. The customer has two brands - Eatery and Appetizer - and the intention is to allow SSO between the two brands so a consumer of Eatery would also be a consumer of Appetizer.
When registering with either brand, it is essential to explicitly communicate to the consumer that they are also registering with the other brand, as they are part of one unique SSO group. Having a central login page allows clear messaging as well as meeting the Intelligent Tracking Prevention specifications.
Below is a representation of the setup.
As a user tries to login to webinar.eatery.com or webinar.appetizer.com, the applications redirect to webinar.cdcsso.com.
The user then lands on the central login page:
The implementation of the central login page consists of:
This ends the blog post where we have shared how to build a secure authentication process while ensuring data privacy and transparency. We have provided the steps to configure password policy, risk based authentication rules and a central login page.
SAP Customer Data Cloud Webinar sessions are carried out by our product experts, covering a variety of topics spanning the full customer journey, from new capabilities, implementation best practices, release information, deep-dive sessions, to integration with other solutions.
Be sure to register for upcoming live webinars on the SAP CX Wiki, and subscribe to the Webinar Channel on enable.cx so you never miss out on new content.
- Ratul Shah – Senior Product Marketing Manager, SAP Customer Data Cloud
- Fred Gasse – Global Practice Lead, SAP Customer Data Cloud
- Stephen Purvis – Product Expert, SAP Customer Data Cloud
- Julien Goulley – Technical Architect, SAP Customer Data Cloud
In the webinar, we discussed how Customer Data Cloud can be leveraged to protect user data using security rules, and to take advantage of SSO capability while ensuring transparency and meeting data privacy agreement.
If you were not able to attend the live session, you can find a link to the recording here.
Ratul and Fred discussed the importance of data privacy, described Customer Data Cloud functionality available to ensure that data and applications are accessed by trusted users, and finally highlighted how WebKit Tracking Prevention Policy is designed to prevent cross-site tracking in order to provide full control to the end user and avoid any miss-use of data by third party applications.
This blog post will explain how to strengthen security by defining a password policy and Risk Based Authentication rules, and implement SSO considering new browser security processes. During this webinar, we used the Webinar demo site created in a previous Webinar in August 2019.
Authentication security
First, it is important to note that Customer Data Cloud securely stores passwords in their hashed form in order to avoid exposure of plain text passwords. However, hiding plain text passwords is not sufficient to protect user data. It is therefore critical to have the ability to define password policy as well as authentication security measures.
Password policy
Customer Data Cloud allows password policy to be configured easily from the Console. In the event that the end-user application implements screensets then the forms (registration, password change) will react accordingly without any further changes.
The below parameters are available:
- Minimum length
- Minimum character groups: defines the complexity i.e. upper case, numbers, special characters
- Regular Expression: allows a stricter password policy
- Regular password change
- Forbid password reuse
These parameters can be found in the Settings section under Policies in the Console, as per the below screenshot.
Risk Based Authentication (RBA)
Rules
Risk Based Authentication provides the ability to create rules which trigger Actions (IP/Account lock, Captcha, TFA) based on events (Failed logins, IP/Device/Country change).
There are 2 types of rule:
- Global rules: these rules apply to all login attempts
- Account-based rules: these rules are applied to an account by an administrator or end user, depending on the Account Rule-Set Override settings
When building a rule, you need to define 2 sections:
- Factor(s): If all factors defined are met during login then the rule is triggered. Note that it is possible to enforce the rules for a subset of apikeys in order to support use cases where different applications require different level of security. Below is a sample factor for 3 failed login attempts on a specific child apikey:
{
"factors": [
{
"type": "failedLogins",
"scope": [
"account"
],
"threshold": 3,
"resetInterval": 3600
},
{
"type": "apiKey",
"apiKeys": [
"<apiKey1>"
],
"inclusive": true
}
]
}
- Action: This is the security measure which is then applied:
{
"duration": 600,
"scope": [
"account"
],
"type": "lockout"
}
These rules can be created from the Console under the RBA section:
Advanced Actions
reCaptcha
CAPTCHA is designed to ensure the authentication is not performed by a robot. In the event Captcha is triggered during the login, the end user will need to run through the Captcha process (i.e. click "I'm not a robot" and/or select the appropriate pictures) in order to complete authentication.
Note that only reCaptcha v2 is currently supported during login. Also note that invisible reCaptcha is available for registration, however this does not require a RBA rule.
Two Factor Authentication (TFA)
TFA is an additional verification method which relies on the ownership of a registered email, mobile phone number or mobile device in order to complete authentication.
When creating a rule for TFA, you will need to provide the minimum level required in order to complete the validation:
- Level 10: This is the lowest level. The validation is completed once the user enters a 6 digit code which is sent to them via email
- Level 20: This is the medium level and it comes with multiple options:
- 6 digit code sent via SMS
- 6 digit code communicated via voice call
- 6 digit code generated by an authenticator application
- Level 30: This is the highest level. Instead of sending a code, a push notification is triggered on the registered mobile device; the end user can then approve the request by the click of a button. More implementation details can be found on the developers.gigya.com site. Note that push notification can only work with a dedicated mobile application.
These different options can also be setup from within the Customer Data Cloud Console, as per the below screenshot:
Central Login Domain
In the example below, we will imagine that we are working with a customer who is managing food catering. The customer has two brands - Eatery and Appetizer - and the intention is to allow SSO between the two brands so a consumer of Eatery would also be a consumer of Appetizer.
When registering with either brand, it is essential to explicitly communicate to the consumer that they are also registering with the other brand, as they are part of one unique SSO group. Having a central login page allows clear messaging as well as meeting the Intelligent Tracking Prevention specifications.
Below is a representation of the setup.
As a user tries to login to webinar.eatery.com or webinar.appetizer.com, the applications redirect to webinar.cdcsso.com.
The user then lands on the central login page:
The implementation of the central login page consists of:
- Create brand applications
- Create brand site as described in this blog
- Redirect the user to the Central Login Page instead of embedding the login screen to the branded sites
<a id="login-btn" class="nav-link" href="javascript:window.location.href='https://webinar.cdcsso.com/webinar/clp/main/index.html?lang=en&redirecturi=' + encodeURI(window.location.href)">Login</a>
- Create Central Login Page
- Load the webSDK
<script type="text/javascript" src="https://cdns.gigya.com/js/gigya.js?apiKey={{apiKey}}"></script>
- Display the login screen
var params = {
screenSet: 'Default-RegistrationLogin'
}
gigya.accounts.showScreenSet(params);
- Redirect to the branded site onLogin
gigya.accounts.addEventHandlers({
onLogin: function(e) {
window.location.href = 'https://webinar.eatery.com';
}
});
- Load the webSDK
- Configuration
- Define a CNAME
- Define the central domain
- Define a CNAME
Conclusion
This ends the blog post where we have shared how to build a secure authentication process while ensuring data privacy and transparency. We have provided the steps to configure password policy, risk based authentication rules and a central login page.
Webinar sign up:
SAP Customer Data Cloud Webinar sessions are carried out by our product experts, covering a variety of topics spanning the full customer journey, from new capabilities, implementation best practices, release information, deep-dive sessions, to integration with other solutions.
Be sure to register for upcoming live webinars on the SAP CX Wiki, and subscribe to the Webinar Channel on enable.cx so you never miss out on new content.
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
