Enhancements and Features

• Customer Identity
  • Custom Login Identifiers
  • Multiple Account Emails
  • New TFA UI Builder Widgets
  • Security Notifications using Account Takeover Protection (ATO)
• Integration
  • SAP Identity and Authentication Service (IAS)
  • SAP Customer Data Cloud / Emarsys Integration
  • Data Quality Management (DQM) support
  • System for Cross-Domain Identity Management (SCIM) support
  • SAP Cloud Identity Services integration
• Other
  • B2B: CIAM for B2B Business Entities
  • ECPM: Communication Channels and Topics
  • Platform: Dynamic Data Access Filters Added to Permissions Groups
  • Other minor changes

Custom Login Identifiers greatly simplify your back-end integrations with internal systems or services that retain an internal customer reference.

Some use case examples: Frequent Flyer ID, Loyalty ID, or any internal reference number used by your internal system

You can add up to 7 custom identifiers that match the customer data-id of the connected external systems.

Custom user IDs can be populated in SAP Customer Data Cloud by the accounts.setAccountInfo REST API or by end users when they register into the system or perform profile updates.

Once a custom identifier has been created in SAP Customer Data Cloud and populated with a custom user ID, you can use it to retrieve user accounts using custom IDs of specific users in the relevant internal systems (via accounts.getAccountInfo or accounts.search, see APIs for Custom Login Identifiers for details).

To define Custom Login Identifiers, go to Console > Advanced > Accounts Schema, and open the Custom Identifiers tab

You can now add verified and unverified emails to an existing account. This feature bypasses the email verification policy defined on the site.

This API call does not affect the profile email or login IDs.

The capability is delivered only through two REST-based APIs: accounts.addEmails and accounts.removeEmails.

For more details refer to the following: accounts.addEmails RESTand accounts.removeEmails REST

Many OTP and TOTP authentication options are available: Push (using other authenticated and registered devices), Authenticator codes, SMS, e-mail, and Backup Codes.

• Several Two-Factor Authentication (TFA) features are easily available on the new TFA Widgets inside the UI Builder
• The TFA Registration and TFA Verification widgets are available for the Registration screen.
• The TFA Management widget is available for the Profile Update screen.

The customer can also erase TFA-registeredFA registered devices.

If you have already implemented TFA using the legacy widgets, and you wish to use the latest TFA Registration, TFA Verification, and TFA Management widgets with the latest Two-Factor Authentication functionality in your existing screens, you must first add these widgets to the existing screens. The widgets presented in the end user flows below include these new widgets and those used in standard login and verification flows.

You may also use the legacy widgets, but the new widgets offer customization that is not available in the legacy widgets.

If you want to use the latest screen-sets to implement TFA, you will not need to manually add the new widgets, as they are included in the latest screen-sets.

Receive security alerts to email when suspicious activity is detected on an account.

Navigate to the Administration section of the Console and select the Security Notifications menu item.

Define up to 5 e-mails for these notifications and which sites will be monitored (by default, all sites are monitored if none is selected).

Customers with multiple SAP solutions can now access SAP Identity and Authentication Service via a single IAS (Identity and Authentication Service) system, which offers simplified configuration and a seamless Single Sign-On experience.

For more information on integrating IAS with SAP Customer Data Cloud your end users can now navigate backwards while using Native, refer to Activating IAS and Logging into the SAP Customer Data Platform Universe.

As part of the provisioning process, the IAS system automatically does the following:

• Creates a tenant in SAP Customer Data Cloud.
• Creates a tenant in IAS (if it doesn't exist yet).
• Creates a partner in SAP Customer Data Cloud under the tenant.
• Creates a bundled application in IAS.
• Sets the Trust configuration between IAS and SAP Customer Data Cloud using the SAP Customer Data Cloud metadata.
• Sets the User Application Access to "Internal", such that only existing IAS users can access the IAS application.
• Sets Risk-Based Authentication (RBA) to TFA TOTP. This setting means that whenever an admin logs into SAP Customer Data Cloud via IAS, they need to enter a one-time password as part of TFA (Two-Factor Authentication).
• Sets the SAML settings in SAP Customer Data Cloud so that SAP Customer Data Cloud trusts IAS, using the IAS tenant metadata.

To configure the connection between Emarsys and SAP Customer Data Cloud:

• Copy the Emarsys API user credentials into the Console.
• Setup field authorizations in Emarsys.
• Filter the SAP Customer Data Cloud accounts to be integrated with Emarsys by custom criterias.
• Configure the Emarsys e-mail and SMS consent mappings.

For more details refer to Emarsys Settings.

Integration with SAP Data Quality Management (DQM allows you to validate and improve the quality of your address data.

Just provide the following:

• The URL, Authentication Address, and Client Credentials configurations from SAP DQM.
• New Address field type on the accounts schema
• Support for Address field and SAP DQM pre-defined lists on the Web Screen-sets.

SAP Customer Data Cloud helps you exclude fake, faulty, or nonexistent addresses and addresses with typos or misspellings that users entered. By checking and validating typed addresses, you gain real, correct, and clean user addresses to improve your data quality. SAP Customer Data Cloud communicates with SAP Data Quality Management, microservices for location data, and provides these integrated functionalities:

• A list of up to 20 validated address suggestions
• Type-ahead functionality (optional)
• Browser geolocation support (optional, end-user opt-in/opt-out)

For more details refer to Data Quality Management (DQM).

SCIM (System for Cross-Domain Identity Management) is an open API specification for easily managing users across domains/applications. SCIM is a RESTful protocol with a defined JSON schema and properties to automate data exchange between services.

For more details, refer to the SCIM specifications, Definitions, Overview, Concepts, and Requirements: RFC 7642

• Protocol
• Core Schema: RFC 7643
• SCIM

SAP Customer Data Cloud now supports the System for Cross-Domain Identity Management (SCIM) protocol (user resource type) and provides an API implementation compliant with the SCIM 2.0 specifications. Our implementation helps you improve data exchange between cloud-based applications and services.

SAP Customer Data Cloud supports the following SCIM user operations:

• createUsers: This API creates a user in the system.
• getUsers: This API retrieves all users from the system. You can use a filter parameter to narrow down results.
• updateUser: This API updates a specific user in the system.
• deleteUser: This API deletes a user from the system.
• getUser: This API retrieves a specific user from the system.

SAP Customer Data Cloud provides an implementation that integrates with the Identity Provisioning service. A central system for authentication, identity provisioning, and user management between various solutions is key to support seamless end-to-end scenarios. If you're using several SAP solutions, you want to provision users and align data across your solutions. Instead of manually provisioning the same users for each application separately, you can accomplish this step in one application integrated into the Identity Provisioning service. This way, users and their data can automatically be propagated to the other integrated systems.

The Identity Provisioning service acts as a proxy system that offers a simple and secure approach to managing the identity lifecycle between source systems (SAP Customer Data Cloud) and target systems (other business applications).

Using SAP Customer Data Cloud as a source system, you can define which users and their associated data you want to share with which other solutions (targets) that are also integrated into the Identity Provisioning service.

Conversely, you can also define in other source systems (Identity Provisioning or other integrated solutions), which users and their associated data you want to share with SAP Customer Data Cloud as a target system. When you create, update, or delete users and their associated data, these changes are automatically synchronized across your SAP solutions.

You can perform Identity Provisioning in either one of the following ways: from SAP Customer Data Cloud to the Identity Provisioning Service or from the Identity Provisioning Service to SAP Customer Data Cloud.

Business Entities are a set of privileges that provide access to different Applications and Assets based on a predefined set of Asset values.

Business Entities are built by assigning Business Entity Attributes in a hierarchical order. Business Entities make it possible to dynamically assign rights to access organizational Assets to a Partner with a high level of granularity due to the hierarchical relationship defined in the Business Entity Types and Rulesets. Business Entities are built within the Partner Manager based on information about the user. For example, where they are located, in what languages they market their offerings, etc.

You can create Business Entities Types and Catalog Entries using the CIAM for B2B Console, and after that, assign them by calling the accounts.b2b.createBusinessEntity REST API endpoint.

Build trust with your users by offering them greater control over the subscriptions to your brand's communication channels and topics.

• Define which topics and channels your brand offers to communicate with your end users.
• Allow your end users to opt in/out and adjust the channels and topics they want to get communicated by your brand.

The communication topics configuration includes the following information:

1. Defining Communication Channels. You can define communication channels by which you interact with your end users, such as email, SMS, social networks, etc. To define communication channels via the SAP Customer Data Cloud console or API, see Defining Communication Channels.
2. Defining Communication Topics. You can create different brand communications to which your end users can subscribe. To create communication topics via the SAP Customer Data Cloud console or APIs, see Defining Communication Topics.
3. Associating the communication topics to the UI. You can associate communications to the UI via dedicated widgets in the UI Builder or APIs. See Adding the Subscription Widget to Flows.

Use the Dynamic Data Access tab of a permissions group to define a filter to restrict the accounts accessed via that permissions group.

To begin, navigate to the Permissions Groups page of the SAP Customer Data Cloud console in the Administration section.

Once a filter is applied to a permissions group, any admin assigned to this group can only see the user's account data that passes the filter criteria. This applies to both the Identity Access section of the console and the accounts.search API.

It is important to note that filters are cumulative, so if an admin belongs to multiple permissions groups and more than one has filter criteria, the admin will have access to all accounts that pass either of the filters.

• Other Minor Changes

• You can now include customIdentifier fields as claims in the returned id_token from the accounts.getJWT API
• We now support an Addresses schema field type, a nested object with a predefined structure and specific properties. You can configure and customize multiple addresses in SAP Customer Data Cloud's UI Builder and screen-sets. The addresses are also available in Identity Access  Profiles.
• Customers now have greater control over the values available in the birth year dropdown box in the UI Builder.
• You can now create a style library for a component and create and modify styles to be applied to your components and across screen-sets.
• New support for a biometric library in the Flutter plugin has been added, allowing developers to integrate secure biometric functionalities into their applications.
• Users in global access sites can now link accounts using one-time password methods when they have an email in their account.
• Global Sites Now Support Email Magic Link.
• You can now configure the "Show Password" behavior in password input fields using an icon or text. The behavior is configurable and will be enabled by default when creating screen-sets. Existing screens can enable this feature manually.
• Additional log providers are now supported by the Log Connector: AwsCloudWatch, Dynatrace, ElasticCloud, HTTP, NewRelic, and SumoLogic.
• New API accounts.b2b.getAccountOrganizationInfo now allows customers to retrieve all relationship information between a user and an organization, including policies assigned to the user (whether through manual or automated assignment) and applications the user can access.
• Global Access implementations now support passwordless authentication using email one-time passwords. 
• We have added the following KPIs to the partner dashboard: Logins by Provider and Failed Logins.
• Admins can configure a JWKS URL on the OIDC RP inbound federation configuration. Our system will automatically use the JWT keys returned from the URL to verify signed JWT tokens from the OP.
• The OAuth2 client credentials flow allows one to authenticate and get an access token that can be used in server-to-server scenarios without connection to specific users.
• New webhook event version 3.0 now allows you to include the parameters of the triggering API call to the event payload for AccountCreated, AccountUpdated, and AccountRegistered events, removing the need for extra API calls in your API implementation to understand what account data was added / updated.
• Introducing the new on-screen experience for the delegated admin console that can be activated from the delegated admin console settings.
• Admins may now rotate the JSON Web Key to sign the JWT tokens within their OpenID Connect OP service.
• A new component datasource.read.gigya.organization is now available for dataflows, allowing customers to build organization exports to 3rd party systems using Identity Sync.
• Using the datasource.read.gigya.account and datasource.read.gigya.audit steps, you can now set up dataflows based on time constraints (for example, last login > 2 years)t up dataflows based on time constraints (for example, last login > 2 years), without having to perform a complete extract of the database.
• Users can now manage multiple two-factor authentication (TFA) devices of the same type.
• SAP Customer Data Cloud's SAML service can now retrieve and return the authentication method from the "AuthnContextClassRef" values in the SAML response.
• SAP Customer Data Cloud has extended FIDO support to out-of-the-box screen-sets for passwordless registration. This allows new users to register without a password or phone OTP by adding a passkey during registration.
• As an admin, you can now configure the lifetime of a refresh token used in OpenID Connect flows.
• Additional authentication and b2b endpoints were added to the list of endpoints monitored by the Log Connector.
• Group webhooks can now be configured from the console. 
• The new SDK Management screen allows the admin to increase security by validating the SDK version used by a specific call to the platform.
• Added the Organization's BPID in the duplicate registration check. Now, it displays the list of duplicate organizations at the top of the screen.
• You can now select and edit an email template for Unknown Location Notification in the Console.