SAP Community - SAP Identity Management

SAP Cloud Identity Services - New Features updates for 11th March 2025

2025-03-15T14:44:13.283000+01:00

Cloud Identity Services - Authorizations Based on Policies

You can now restrict the access to the administration console only to one user type via the new attribute that is supported for authorizations based on policies - user.type.

Reference Documentation ; Configure User Authorizations

Cloud Identity Services - Identity Federation for Applications

You can enable identity federation for an application to override the identity federation settings on the configured corporate identity provider for the application.

Choose if user attributes will be taken from the corporate IdP assertion or from Identity Authentication user store. Restrict access based on user profile.

Cloud Identity Services - SAML 2.0 Configuration

The SAML 2.0 configuration page on application level has been refactored from March 11th 2025 release. Now you can separately configure the metadata and certificates setting

Cloud Identity Services - Attributes Based on Flexible Expressions

The display name of Groups attribute based on flexible expressions for the application is renamed to All Groups.

Reference Documentation : Configure Attributes Based on Flexible Expressions

SSO implementation in GROW with SAP using Microsoft Entra ID

2025-03-18T16:56:18.305000+01:00

The SAP Single Sign-On application enables users to log in once to gain secure access to all the software they require throughout the day with no need to log in again ,with SAP Single Sign-On

There are several process to set up setup SSO in On premise system as well as on cloud, here we will discuss SSO setup between Azure and SAP on Public Cloud using IdP

There are two primary options in which SAP Identity Authentication Services and Microsoft Entra ID can be integrated:

Microsoft Entra ID as the Identity Provider (IdP): This scenario makes Microsoft Entra ID the central authentication hub, with users logging into SAP applications using their Microsoft Entra ID credentials.

SAP IAS as the IdP: In this case, SAP IAS becomes the primary authentication source, with users logging into Microsoft Entra ID applications using their SAP credentials.

Recently I got opportunity to setup SSO between Microsoft Entra ID (formerly known as Microsoft Azure Active Directory or Azure AD) , SAP IAS and SuccessFactors on SAP on Public Cloud (Grow with SAP) using SAP IAS as the IdP.

Below are step to configure SSO between Azure ,IAS and Success Factor.

1- Configure SAP IAS

Login on IAS system go to Applications and Resources -> Tenant Settings ->Single Sign On-> SAML 2.0 Configuration the download metadata file on you system share this file to Azure team and ask for Federation Metadata XML

2- Configure Microsoft Entra ID

This setp should be perform by azure admin system by following step

Create an Application in Microsoft Entra ID: This application represents your SAP IAS instance. Login to https://portal.azure.com and setup the Microsoft Entra ID.

Click Add -> Enterprise Applications

By default, Microsoft Azure supports variety of applications. Search with SAP Cloud Identity Services. Select the SAP Cloud Identity Services and click on create.

We will be using the SAML Metadata file to setup the trust between Microsoft Entra ID and SAP Identity Authentication service (IAS). Click on Setup Single Sign-On.

Choose SAML as the SSO method and upload the SAP IAS metadata file.

After saving the application you can download the Federation Metadata XML file which we will add to the SAP Cloud Identity Services (IAS).

3- Configure Federation metadata on IAS

Click on create

Fill are require data

Click on create it will create entry in Identity provider

Now click on SAML2.0 Configuration

And upload azure xml file

All setting between Azure and IAS system has been done.You can check SSO connection via login on IAS system ,it will pick Azure authentication and will login without asking password on IAS system

Now going to setup SSO connection between IAS and managed application system here I will setup connection between IAS to success factor, you can choose other system depend on requirement

Now select single Sign-on and check Subject Name Identifier it should be as below

select single Sign-on and check Default Name ID Format

Check attribute it should be as below

Now maintain domain in Conditional Authentication as per below

All setting has been completed for SF system

Now login to sf provision url and enable SSO

Now test sso from SF system it will automatically login on system without login page

Reference

SAP IAG intergration with SAP Analytical cloud (SAC)

2025-03-20T18:29:42.868000+01:00

SAP Cloud Identity Access Governance (IAG) serves as a pivotal cloud-based solution, orchestrating identity and access management across intricate hybrid environments. By centralizing access request processes through a user-friendly, self-service portal, IAG streamlines provisioning for both on-premises and cloud applications, including seamless integration with SAP Analytics Cloud.

The first step is configuring SAP Cloud Identity Access Governance (IAG) within SAP Business Technology Platform (BTP) environment involves establishing a proxy destination. Specifically, the creation of the IPS_PROXY destination within your subscriber subaccount is paramount for seamless communication and functionality.

Step 1. Create Proxy Destination in BTP is not created.

Navigate to the subscriber subaccount for SAP Cloud Identity Access governance in SAP BTP and create a destination with the name IPS_PROXY as shown in the table below.
Enter the Properties listed in the table below for the destination. All properties must be entered. Some properties must be added as Additional Properties. Copy the names of all properties as displayed. Property names and values are case sensitive.
The url in the above can be fetched from CIS cockpit.
For user and password
1. Go to the Identity Authentication, Users Authorizations-> Administrator and enable the option Manage Identity Provisioning for your user.
2. Open your Identity Provisioning and navigate to Security Authorizations Manage User Authorizations -> Administrators.
3. In the section Users & Authorizations Administrators, Add System for Identity Provisioning and Configure Authorizations for the Access Proxy System API. Note down the Client ID and Secret (once the secret is generated, you cannot retrieve or change it.).
  
  Step 2:Create Proxy system for SAC in CIS.
  Maintain the properties exactly as shown:
  The OAuthtoken, user, URL and password is to be fetched from SAC.
  In SAC: Goto system-> Administrator
  Step 3: Create application in IAG.
  Run Repository sync.
  
  This completes the SAP Cloud Identity Access Governance (IAG) integration with SAP Analytics Cloud, enabling centralized, secure access management

Regards
JP

Integrating SAP Cloud Identity Services (Identity Authentication - IAS) with SAP Audit Log Viewer

2025-03-23T20:29:50.328000+01:00

Previous Blog : https://community.sap.com/t5/technology-blogs-by-sap/how-to-enable-sap-audit-log-viewer-service-to-collect-all-audit-logs-from/ba-p/14037435

Accessing Audit Logs for Identity Authentication Tenants

To access the audit logs for changes in personal data, successful, and failed authentications for Identity Authentication tenants on both SAP, AWS, and Azure infrastructures, you can use the Audit Log Service in SAP BTP, Cloud Foundry. This process is essential for organizations that require detailed auditing to ensure that changes are tracked accurately.

Why is this Important?

Auditing is crucial for maintaining the integrity and security of your organization's data. By tracking who made changes, you can ensure accountability and transparency within your system.

Steps to Access Audit Logs

Navigate to the Audit Log Service: Access the Audit Log Service in SAP BTP, Cloud Foundry.
Filter Logs: Use filters to view logs related to changes in personal data, successful authentications, and failed authentications.
Review and Analyze: Carefully review the logs to identify any unauthorized changes or any suspicious activities.

Benefits

Enhanced Security: By monitoring audit logs, you can detect and respond to security breaches promptly.
Compliance: Ensure your organization meets regulatory requirements for data protection and privacy.
Accountability: Track changes to identify responsible parties and maintain accountability

Prerequisites for enabling Auditlogs Viewer for SAP Identity Authentication - Audit logs

Pick your subaccount details and you must have SAP Cloud Identity Services and Auditlog Viewer Services enabled already.

Once above details are available, you can now follow the below steps to tie the application between SAP Cloud Identity Services and Auditlog Viewer Services

Step 1 : Login to your SAP Cloud Identity Services - Admin and go to Monitoring & Reporting Tile

Step 2 : Click Add to update configuration of your SAP BTP Tenant details (from above prerequisites steps)

Step 3 : Update your BTP Tenant Id and Subdomain which should match to the region shown in dropdown. List of available regions are in below link.List of Available Regions for Identity Authentication - Cloud Foundry Regions Mapping

Step 4: Once configured,you will be able to see the Subaccount Information and Auditlog viewer Link and you will have to wait for 15-20mins once configured to see the logs in Auditlog Viewer Portal.

Step 5 : Upon accessing the Audit Log Viewer, you have the option to filter the logs based on date and keyword filters.

The audit logs provide information about the event category and timestamp, the event and object type, who performed the action and others.

New Business Technology Platform Capabilities: Customer Identity and Consent Management

2025-05-06T13:00:00.026000+02:00

Today, SAP Business Technology Platform now includes our industry leading Customer Identity and Access Management (CIAM) solution through the BTP Enterprise Agreement. This highly scalable solution supports over 2.9 billion identities and 17.7 billion consent records.

Why SAP CIAM?

With SAP CIAM, you can deliver seamless customer experiences while upholding stringent security standards and accelerating growth. By harnessing your customer’s data effectively and responsibly, this solution empowers businesses of all sizes to bridge the numerous data strategy gaps that emerge in today's digital-first landscape — where there are more touchpoints to manage, engagement channels to orchestrate, and data points to collect than ever before. The power to personalize is easier than ever with consent based first-party data.

Explore this KuppingerCole report to learn how our CIAM solution stands out.

What is SAP CIAM?

SAP CIAM is a comprehensive identity solution which transforms customer data into actionable insights. Designed to function as a brand’s digital front door, this multitenant, cloud-native software plays a critical role in data strategy; it enables organizations to effectively capture and manage both customer and partner data while enhancing security and privacy and delivering personalized experiences.

By providing access to intelligent insights across the business landscape, SAP CIAM equips businesses to:

Secure users and safeguard data

Prioritize business protection with AI

Reduce privacy compliance risk

Overcome data silos

Increase efficiency at scale

Discover how SAP CIAM can elevate your business today.

How does SAP CIAM work?

SAP CIAM streamlines identity creation and authentication across digital platforms, allowing easy registration management for various devices. It securely stores and enriches customer data with each digital transaction, offering options like social login and biometrics for secure access. By assembling robust customer profiles, SAP CIAM helps businesses personalize experiences, boost engagement, optimize customer journeys, and make informed decisions while integrating seamlessly with existing systems.

Dive into more solution details with this short video.

Who needs SAP CIAM?

Any business that manages digital transactions can benefit from SAP CIAM. Today, it’s now more crucial than ever that organizations find a way to capture –– and manage –– customer and partner data because every online interaction is an opportunity to acquire user information, develop brand loyalty, and deepen trust.

SAP CIAM is available with both a B2C implementation and a B2B implementation.

Getting started with SAP CIAM

SAP CIAM is now available as part of the Business Technology Platform Enterprise Agreement (BTPEA). Existing consumption credits can be used on this solution, empowering your business to conveniently handle identity, consent, and authentication without entering into any new contracts. Learn more here.

Introducing the new Terraform Provider for SAP Cloud Identity Services – Now in Beta!

2025-05-16T19:05:47.308000+02:00

We’re excited to announce the beta release of the Terraform provider for SAP Cloud Identity Services. Built based on customer feedback and feature requests, this provider is a much-awaited step forward in simplifying identity management.

Why Automate SAP Cloud Identity Services?

It provides a secure, centralised approach to identity and access management across systems, making it an important part of any modern SAP landscape.

As your organisation grows, scaling identity & access management starts to become a challenge, and automation becomes essential.

With this new Terraform provider, you can bring infrastructure-as-code (IaC) practices to your identity environment, delivering:

Repeatability
Auditability
Governance
Faster deployments

What’s in the Box? 🚀

The provider will be developed in a phased and scoped manner. It will evolve based on feedback, requirements, and user scenarios.

In this beta release, our focus is on foundational resources that are central to identity & authentication:

Application

Applications represent consumers of Identity Authentication such as SAP cloud solutions, third-party apps, SAP BTP subaccount, etc.

Terraform Resource: Configure identity settings for applications.
Data Sources: Retrieve details of specific applications or list all applications within a tenant.
📘View Docs

Group

Groups help organise users based on roles, permissions, or other criteria.

Terraform Resource: Create and manage user groups.
Data Sources: Fetch details of individual groups or get a complete list.
📘View Docs

User

Programmatically manage end users with the ability to automate user lifecycle operations.

Terraform Resource: Define and manage end users.
Data Sources: Query individual users or list all users in a tenant.
📘View Docs

Schema

Need custom attributes for your users? Define and manage user schemas to match your organisational needs.

Terraform Resource: Configure custom user schemas.
Data Sources: Retrieve details or lists of schemas.
📘View Docs

The provider is open-source under the Apache 2.0 license, and powered by the public APIs published on the SAP Business Accelerator Hub.

A Quick Word on Beta

This is a beta release, which means it’s an early version, intended for exploration, experimentation, and feedback.

Important Notes:

Do not use it in production just yet.
This release is for trial and evaluation only.
Definitions, behaviour, and features may change in future releases based on:
- Community feedback
- API limitations or updates
- Real-world use cases
- Bugs or usability issues

We Want Your Feedback!

As you test it out, let us know:

✅ What works well?
🐞 What’s broken?
💡 What features or resources would you like to see next?
🔁 What automation scenarios are you trying to solve?

You can file issues, open feature requests, or share scenarios and feedback directly on the provider’s GitHub repository. We’ll do our best to address them.

Where to Get It?

The provider is now available on the Terraform & OpenTofu registries:

We’re thrilled to take this step forward in supporting SAP Cloud Identity Services automation and can’t wait to see what the community builds with it.

🧪 Try it out.
🛠 Break things.
💬 Tell us what you need.

Let’s build something awesome together!

Shift identity management from SAP IDM to SAP IAG with CIS and GRC AC.

2025-06-03T10:21:50.898000+02:00

Disclaimer-It is recommended to conduct an SAP IDM assessment to evaluate the feasibility of migrating existing functionalities to SAP IAG, CIS, or GRC Access Control. The approach in this blog is particularly suitable for customers who primarily use SAP IDM for managing access in SAP systems, whether on-premise or in the cloud.In a more complex and heterogeneous enterprise-wide environment, customers are most likely to rely on a third-party identity management solution. Refer this blog that highlights our partnership with Microsoft to position MS Entra as a successor for SAP IDM.

SAP provides a comprehensive suite of identity and access management (IAM) solutions to help customers manage user identities across their SAP applications, both on-premise and in the cloud. These solutions include SAP Identity Management (SAP IDM), SAP GRC Access Control (SAP GRC AC), SAP Cloud Identity Services (comprising Identity Authentication and Identity Provisioning), and the SAP Identity Access Governance (SAP IAG) service.

SAP IDM, the long-standing on-premise IAM solution that has supported customers for over two decades, is approaching the end of its maintenance lifecycle (refer to SAP Note 3268799). Organizations currently using SAP IDM and planning a migration strategy can consider leveraging SAP IAG, SAP Cloud Identity Services (CIS), and their existing SAP GRC Access Control systems to cover identity lifecycle management needs. In many cases, the combination of SAP IAG with CIS—or SAP IAG with CIS and a bridge to SAP GRC Access Control—can replicate most of the functionalities previously handled by SAP IDM.

SAP IAG and SAP CIS are designed to complement each other and are often deployed together in enterprise environments to deliver end-to-end identity and access management. Additionally, SAP IAG can be integrated in a bridge scenario with SAP GRC Access Control to reuse existing configurations and ensure a smooth transition.

Feature / Solution	SAP IAG	SAP Cloud Identity Services	SAP GRC Access Control
Deployment	Cloud	Cloud	On-premise / Hybrid
Primary Focus	Access governance & compliance	Authentication & identity provisioning	Risk management & compliance
Authentication (SSO, MFA)	No	Yes	No
Access Risk Analysis	Yes	No	Yes
Access Request Management	Yes	No	Yes
Role Management	Yes	No	Yes
Privileged Access Management	Yes	No	Yes (via EAM)
Best Fit For	Cloud-first organizations	Identity and access security	Regulated industries with complex needs

IDM Functionalities

This section outlines the SAP IDM functionalities along with their corresponding equivalents in SAP IAG, CIS, and GRC Access Control. The relevance of each activity may vary depending on the specific SAP IDM implementation within an organization.

IDM Functionality	As-Is Configuration (SAP IDM)	Corresponding Functionality in IAG / CIS / GRC AC
System Connectivity – SAP & Non-SAP Systems	List of systems supported via SAP IDM packages: ABAP Business Suite, ABAP (Load Balanced), AD, AS Java, BW, Dual Stack, HANA DB, S/4HANA, SCI (IAS/IPS), SCIM (IPS Proxy), SuccessFactors (SFSF), Sun (AD), GRC	CIS: Supported Systems IAG: Integration Scenarios
Data Source	SuccessFactors, HR Mini Master, AD (On-Prem/Cloud), third-party DBs	IAG: Integration Scenarios GRC AC: LDAP, HR triggers for position based assignment, HR Triggers from SuccessFactors, ABAP, or custom)
Role Type	Technical Roles, Business Roles	IAG: Role Design Service GRC AC: BRM Module
GRC Integration – Risk Analysis	Risk Analysis/Risk Analysis only	IAG: Standalone Version IAG Bridge with GRC Access Control
Approval Workflows	Maintained Users/ Pending Value Objects	IAG: SAP Workflow Management Service GRC AC: MSMP Workflows (Bridge Scenario)
Entry Owners	Maintained / Not Maintained	IAG / IAG Bridge: IAS User Groups GRC AC: Bridge Scenario (Parameter 1090: No)
Self-Services	Password Self-Service, Role Requests	GRC AC: Password Self-Service
Attestation (User Access Review)	User Access Review	IAG: Access Certification GRC AC: User Access Review (UAR)
Mass Upload Utility	Upload Users, Roles, Privileges, Mappings via Excel	IAG: Access Mass Update, Business Role Mass Update GRC AC: Excel Uploads (Bridge Scenario)
Custom Notifications	Custom Notification Messages	GRC AC: Custom Notifications
IDM Reports	Reports from IDM DB	IAG: Reports GRC AC: Reports
Custom Configurations	Custom or Enhanced Functionalities (e.g., HTML5 Forms)	Handled on a Need Basis
Audit Logs	Activity-Based Logging	IAG: BTP Audit Log Service GRC AC: Audit Logs (Bridge Scenario)

Discover SAP's approach to identity and access management (IAM) within the framework of the identity lifecycle through the following links- IAM reference architecture and CIO Guide.

How IAS and IPS Help Secure SAP SuccessFactors

2025-06-13T10:25:23.988000+02:00

Hey SAP Community! If you're like me, you're always trying to make business apps easier and safer to use. Today, I want to chat about two tools that help with that: Identity Authentication Service (IAS) and Identity Provisioning Service (IPS). They’re big players in SAP, especially for managing users in SAP SuccessFactors. But what do they actually do, and why should you care? Let’s break it down!

What is IAS?

Think of IAS like the front door to your apps. It makes sure only the right people get in. IAS helps you by letting users log in once and access everything they need without logging in again (that's called single sign-on or SSO). Plus, you get to pick how users log in, whether it’s with a password, a social media account, or even using two steps for extra security.

Cool Things IAS Can Do:

Easy Login (SSO): Users love not having to log in over and over on different apps. It's super convenient.
Extra Security: You can require more login checks based on who the user is or where they are logging in from. This keeps your apps safe.
Works with Other Services: Got Microsoft Azure Active Directory? No worries. IAS can talk to these outside services so everything works together smoothly.
Manage Setup with API: Using the tech behind IAS, you spend less time tweaking settings and more time using your apps.

IAS is like the guard at the entrance, keeping everything secure without making it complicated.

Getting to Know IPS

Now onto IPS! It’s not just a fancy name. If IAS is the front door, IPS is the key that makes sure everyone has the right access. It makes managing user identities simple across both cloud systems and systems running internally on your company's hardware.

Cool Things IPS Can Do:

User Management: IPS jumps in after you're set up with IAS to ensure everyone gets the right access on all platforms. Think of it like your personal assistant for user access.
Data Control: You don’t need all data everywhere. With IPS, you can control what goes where and tailor it to your needs.
Transparency and Notifications: IPS keeps you informed with logs and notifications about what's happening with user provisioning. You always know what's going on.

IPS works quietly behind the scenes, giving users access smoothly without manual hassle.

Why IAS and IPS Matter

You might be thinking, "Do I really need these services?" Absolutely, yes! SAP wants to make sure identity authentication is simple and pre-configured in their systems. This means less worry about user access.

IAS can also manage other identity providers, integrating them easily into your workflows. You get strong security and ease in one package.

Setting Up IAS/IPS

Wondering how to set this up? You’re not alone. IAS/IPS comes with many SAP cloud services, but you can also set them up through SAP Business Technology Platform. The best place to start is SAP's Tenant Discovery link to see if you have them ready.

Customizing and Using IAS/IPS

After setup, you can customize login pages, email templates, and usage terms. Check out SAP’s help documents for detailed guides on making the most of IAS/IPS:

Wrapping Up

So there you have it, a simple look at why IAS and IPS are key for SAP SuccessFactors and other SAP cloud systems. They make life easier for you and your users, ensuring smooth and secure access. I hope this helps you understand these great tools better. Until next time, keep your identities safe and your systems secure!

Identifying SAP Certificates in Personal Security Environment: A Comprehensive Guide

2025-06-18T19:35:52.547000+02:00

Understanding Personal Security Environment (PSE) Fundamentals

At its core, a Personal Security Environent (PSE) in SAP is a digital container designed to securely store cryptographic information, primarily digital certificates and their corresponding private keys. Think of it as a digital wallet for your SAP system's security credentials. PSEs are essential for enabling secure communication channels, such as those used in SSL/TLS, SNC (Secure Network Communications), and digital signatures.

There are several types of PSEs, each serving a specific purpose within the SAP ecosystem:

System PSE (SSFS): Often used for internal system-to-system communication and secure storage of sensitive data like database credentials.
Application PSE: Employed by specific SAP applications for their secure communication needs.
Client PSE: Used by SAP clients (e.g., SAP GUI, external applications) to authenticate themselves to SAP servers.

PSEs can also exist in different formats, primarily:

Legacy format (v2): An older format that might still be found in some older SAP installations.
Current format (v4): The modern and more secure format, offering enhanced cryptographic capabilities.

The Structure and Components of a PSE

To effectively identify certificates within a PSE, it's crucial to understand its internal structure and the components it typically contains:

Owner Certificate (with Private Key): This is the primary certificate associated with the PSE, along with its unique private key. This pair is used by the SAP system or application to identify itself and encrypt/decrypt data.
Certificate Chain: A sequence of certificates that links the owner certificate back to a trusted root Certificate Authority (CA). This chain establishes the trustworthiness of the owner certificate.
Trust Anchors (Trusted Certificates): These are certificates of trusted Certificate Authorities (CAs) or self-signed certificates from other systems that the SAP system explicitly trusts. They are used to validate the authenticity of incoming certificates.
Address Book (Optional): In some cases, a PSE might also contain an address book of trusted communication partners.

PSE files are typically stored in the file system, often with a .pse extension. Common storage locations include the sec directory under the SAP instance directory (e.g., /usr/sap/<SID>/<Instance>/sec/). For certificates managed within the SAP HANA database, they might reside in database tables such as SYS.CERTIFICATES and SYS.PSE_CERTIFICATES.

To protect the sensitive private keys and certificates, PSEs employ several protection mechanisms:

PIN Protection: A password or PIN is often used to encrypt the private key within the PSE, preventing unauthorized access.
File Permissions: Operating system file permissions are critical to restrict access to the PSE files themselves, ensuring only authorized users or processes can read or modify them.
Database Privileges: For in-database certificates, appropriate database privileges are essential to control who can view, modify, or delete certificate entries.

Dissecting Certificate Structure for Identification:

Before diving into identification methods, let's briefly review the key elements of a digital certificate that aid in its identification:

Distinguished Name (DN) Components: The DN is a unique identifier for the certificate's subject. Key components include:

Common Name (CN): Typically the hostname or application name.
Organization (O): The name of the organization.
Organizational Unit (OU): A specific department or unit within the organization.
Country (C): The two-letter country code.

Key Certificate Attributes: Beyond the DN, other attributes provide crucial identification details:

Serial Number: A unique identifier assigned by the Certificate Authority.
Validity Period: The start and end dates during which the certificate is considered valid.
Issuer Information: Details about the Certificate Authority that issued the certificate.
Key Usage: Defines the cryptographic purposes for which the public key contained in the certificate can be used (e.g., digital signature, key encipherment).
Signature Algorithm: The algorithm used to sign the certificate.

Methods for Certificate Identification

Identifying certificates in SAP PSEs can be approached through various methods, each with its own strengths and use cases.

1. Identification by Location

The simplest form of identification is by knowing where PSE files are typically stored. Standard file paths and instance-specific locations are common starting points. For SAP HANA, certificates might also be found within database collections.

2. Identification by Attributes

Once a certificate is accessed, its attributes can be used for precise identification:

Distinguished Name (DN) Matching: Comparing the DN components against expected values.
Serial Number Lookup: Searching for a specific certificate by its unique serial number.
Fingerprint Comparison: Using cryptographic hash functions (e.g., SHA-256) to generate a unique fingerprint of the certificate for comparison.

3. Identification by Purpose

Certificates are often used for specific functions, which can also aid in their identification:

SSL Server Certificates: Used by SAP servers to secure incoming connections.
SSL Client Certificates: Used by SAP clients to authenticate to servers.
SAML Certificates: Used for Security Assertion Markup Language (SAML) based single sign-on.
Signing Certificates: Used for digital signatures.

Tools for Certificate Identification

SAP provides several tools, both command-line and GUI-based, to help with certificate identification and management.

Using the sapgenpse Tool

sapgenpse is a powerful command-line utility provided by SAP for managing PSEs and certificates. It's particularly useful for scripting and automated tasks.

Key commands for identification include:

sapgenpse get_my_cert -p <PSE_path> -v: Extracts and displays the owner certificate from a specified PSE file.
sapgenpse maintain_pk -p <PSE_path> -l: Lists all certificates contained within a PSE file.
sapgenpse maintain_pk: maintain the server's certificate list within a PSE.

The output of these commands provides detailed certificate information, including validity status and trust chain information.

Using the STRUST Transaction

For those who prefer a graphical interface, the STRUST transaction in SAP GUI is the primary tool for managing PSEs and certificates. It offers a user-friendly way to visualize and interact with certificate data.

Navigate to STRUST via the transaction code. Here, you can select and manage various PSE types. STRUST provides a visual certificate browser, allowing you to view detailed information about each certificate, including its chain, validity, and key attributes. It also supports import and export functionalities.

Python-Based Identification

For advanced automation and integration with other systems, Python scripting offers a flexible and powerful approach to certificate identification. Libraries like cryptography or OpenSSL can be used to parse certificate files, while custom scripts can be developed to interact with SAP systems or database views.

Python-based solutions offer significant automation benefits, including bulk certificate discovery, automated metadata extraction, and proactive expiration monitoring.

Best Practices for SAP Certificate Management

Effective certificate identification is just one piece of the puzzle. Implementing best practices ensures a secure and manageable SAP certificate landscape.

Naming Conventions: Adopt consistent Distinguished Name (DN) formats and use purpose-indicating Common Names (CNs). Include version tracking in comments or metadata.
Organization: Centralize PSE management where possible. Maintain comprehensive documentation of certificate purposes and regularly update your certificate inventory.
Monitoring: Implement automated expiration checks to prevent outages. Regularly validate trust chains and audit certificate usage to detect anomalies.

Common Challenges and Solutions

Managing SAP certificates comes with its share of challenges. Here are some common ones and their practical solutions:

Challenge: Identifying certificates across distributed systems.

Solution: Implement a centralized certificate inventory system with location mapping to track all PSEs and certificates across your SAP landscape.

Challenge: Determining certificate purpose.

Solution: Enforce standardized naming conventions and metadata tagging during certificate creation to clearly indicate their intended use.

Challenge: Legacy format detection.

Solution: Utilize version-aware tools (like sapgenpse with appropriate flags) and plan for systematic conversion of legacy PSEs to current formats.

Challenge: PIN-protected PSEs.

Solution: Implement secure PIN management strategies, potentially leveraging secure credential stores or automation tools that can securely provide PINs when needed.

Conclusion

Identifying SAP certificates within the Personal Security Environment is a critical aspect of maintaining a secure and reliable SAP landscape. It requires a systematic approach, leveraging a combination of SAP-provided tools like sapgenpse and STRUST, alongside powerful scripting capabilities offered by Python.

By understanding the fundamentals of PSE, its structure, and the various identification methods, you can gain better control over your SAP security infrastructure. Adhering to best practices in naming, organization, and monitoring, coupled with proactive solutions to common challenges, will significantly enhance your ability to manage certificates effectively and prevent security vulnerabilities or system outages.

Ultimately, a comprehensive and up-to-date inventory of your SAP certificates forms the foundation for robust security and efficient operations. Embrace these strategies to ensure your SAP systems remain secure and trustworthy.

Enhancing Security in Identity Authentication Service (IAS) with Certificate-Based Authentication

2025-08-17T20:35:45.189000+02:00

🔐Enhancing Security in Identity Authentication Service (IAS) with Certificate-Based Authentication

✨“Moving beyond Client ID & Secret — strengthening IAS with certificate-based authentication for enterprise-grade security.”

About Me

Hare Krishna 🙏 I am an SAP BTP Cloud Architect, sharing practical insights, solutions, and real-world experiences from the SAP ecosystem.

📘Introduction

In modern enterprise landscapes, Identity Authentication Service (IAS) plays a key role in securing access to applications and systems. Traditionally, system user authentication in IAS relied on Client ID and Secret (essentially a username and password mechanism). While simple to implement, it comes with inherent risks—🔑 password leakage and 🗄️ storage vulnerabilities.

To address these challenges, IAS provides the option to use certificate-based authentication, offering a stronger and more secure alternative.

⚠️Limitations of Client ID & Secret Authentication

Although widely used, Client ID and Secret authentication has drawbacks:

🔑Password-like storage: Secrets need to be securely stored, often in encrypted vaults.
🚨Leakage risk: Exposure in logs, code repositories, or integrations can compromise the system.

🛡️ Why Certificate-Based Authentication?

Certificate-based authentication strengthens IAS security by replacing secrets with a cryptographic key pair.

🔒Stronger Security: Asymmetric encryption makes brute-force attacks impractical.
🗝️ No password dependency: Eliminates risks tied to weak or reused passwords.
🛑Leakage-resistant: Public certificate exposure is harmless without the private key.

⚙️How It Works in IAS

👤System User Creation: Generate a certificate instead of a Client ID and Secret.
🔑Public-Private Key Pair:
- The public certificate is uploaded to IAS.
- The private key remains with the consuming application.
🔍Authentication: IAS validates the presented certificate.
✅Access Granted: Secure communication is established.

🔗Real-World Use Cases for Certificate-Based Authentication

So when should you consider using certificate-based authentication in IAS?

This approach is particularly beneficial when:

🌐You need to establish API-based connectivity with IAS from external tools or applications.
🔧A system user is required for integrations, automations, or monitoring purposes.
🛡️ You want to secure machine-to-machine (M2M) communication more efficiently than with Client ID & Secret.

In such scenarios, certificates ensure stronger trust and reduce credential management risks, making them ideal for enterprise-grade integrations.

🖼️ Real-Life Example: Configuring Certificate-Based Authentication in IAS

📂Understanding Certificate Formats Before You Begin

Before we jump into the actual configuration, it’s important to understand the different certificate file formats you may encounter during the process. This helps avoid confusion when handling files like .p12, .crt, and .pem.

✅Key Differences at a Glance

Format Contains Private Key? Contains Cert(s)? Encoding Typical Use

.crt	❌No	✅Yes	Base64 (PEM) or Binary (DER)	Server certificate file
.pem	✅Optional	✅Yes	Base64 (PEM)	Flexible container for certs/keys
.p12 / .pfx	✅Yes	✅Yes (can include full chain)	Binary (PKCS#12)	Import/export in apps, keystores

🔑Practical Flow in IAS Scenario

You generate a .p12 (PKCS#12) file → this includes both your private key and certificate chain.
From this .p12, you typically extract:
- Private Key → required for secure client authentication.
- Full Certificate Chain (.crt/.pem) → ensures trust and proper verification.

👉By understanding this, you’ll know what each file is for and why it’s being used in SAP IAS certificate-based authentication.

Step by Step instructions to perform the activity

Generate .p12 → extract private key (.pem) → extract full certificate chain (.crt/.pem) → upload public cert/chain to IAS (system user) → store private key securely in your app → enable client-certificate auth → test the API connectivity.

Click on Certificate

Provide CN name and password for certificate and click on generate - it will create a .p12 file

Save it.

Open Terminal and enter command (here API_Cert.p12 is the certificate name downloaded from IAS). Post this enter the required fields like passphrase etc.

openssl pkcs12 -in API_Cert.p12 -info

It will have private key and Full chain certificate, Copy the Private key in a text file and save it as .pem file

similarly copy the full chain certificate in a text file and save it as .pem

Upload the full chain certificate in IAS and save it.

Certificate is successfully uploaded in IAS

Let's test it using POSTMAN. Open Postman and go to settings -> Add certificate -> upload the certificate as shown below and provide URL of IAS and password

Perform a get operation to check if connectivity is working fine. You should receive 200 success message like shown below

📝Best Practices for Certificate-Based Authentication in IAS

📆Track certificate validity: Default validity is 1 year — plan renewals in advance.
🗄️ Secure private keys: Store them in HSMs or trusted key vaults.
🔄Automate renewal: Prevent downtime due to expired certificates.
📊Monitor usage: Continuously audit authentication logs in IAS.

🎯Conclusion

Switching from Client ID & Secret to certificate-based authentication in IAS is a major security enhancement. It reduces password-related risks, strengthens trust between systems, and ensures compliance.

By adopting certificates, enterprises can align IAS with modern security standards, making their environment more secure, resilient, and future-ready 🚀.

🔒 Evolving Security in SAP BTP – Goodbye APIAccess Plan, Hello BTP CLI

2025-08-18T22:10:52.716000+02:00

🔐SAP BTP Security Shift: From APIAccess Plan to BTP CLI Credentials

🙋‍ About Me

Hare Krishna 🙏 I am an SAP BTP Cloud Architect sharing practical insights, solutions, and real-world experiences from the SAP ecosystem.

🌟Introduction

SAP is continuously evolving its security and authorization capabilities on the Business Technology Platform (BTP). One major shift is the move away from the APIAccess plan for Authorization and Trust Management Service towards BTP CLI Security API Credentials.

This transition brings more centralized control, enhanced governance, and future-ready security management.

❓Why the Shift?

The APIAccess plan was primarily used for developers to generate OAuth credentials via the cockpit.
SAP has marked it obsolete, pushing customers to adopt the more powerful BTP CLI Security API credential management.
This aligns with SAP’s strategy of delivering CLI-first, automation-ready tooling.

💡Benefits of Using BTP CLI

✅Centralized credential management at the subaccount level
✅Fine-grained, role-based access (requires Security Administrator role)
✅Automation-friendly (ideal for CI/CD pipelines)
✅Better lifecycle management (create, rotate, revoke credentials via CLI)
✅Future-proof – new features/enhancements will come only in BTP CLI

⚖️Key Differences: APIAccess vs BTP CLI Security API Credentials

Aspect APIAccess Plan BTP CLI Security API Credentials

Scope	Bound to a specific service instance	Managed at subaccount level
Access Role	Typically developer role (CF)	Requires Security Administrator role
Management	Created via cockpit UI	Managed via BTP CLI commands
Automation	Limited	Fully automation-ready (CI/CD, scripts)
Future Support	Deprecated / Obsolete	Actively supported & enhanced
Governance	Minimal	Strong audit & lifecycle management

🛠Steps to Manage Security API Credentials via BTP CLI

1️⃣Login to BTP CLI

btp login --url https://cpcli.cf.eu10.hana.ondemand.com --subdomain <your-subdomain>

2️⃣Create Security API Credential

btp create security/api-credential --subaccount <subaccount-guid> --name <credential-name>

3️⃣List Security API Credentials

btp list security/api-credential --subaccount <subaccount-guid>

4️⃣Get Details of a Credential

btp get security/api-credential --subaccount <subaccount-guid> --name <credential-name>

5️⃣Delete Security API Credential

btp delete security/api-credential --subaccount <subaccount-guid> --name <credential-name>

📸Real-Life Example (POC)

btp login --sso

It will open browser to enter userid and password. Once authenticated successfully in browser user will be logged in the BTPCLI

User should have security admin privileges to perform this task using BTPCLI as highlighted below:

Command to create BTP Security api credentials

btp create security/api-credential --name APIConnectivitySecurityCred

Command to list the security api credentials

btp list security/api-credential

Command to get the security api credentials:

 btp get security/api-credential APIConnectivitySecurityCred

Command to delete the security api credentials:

btp delete security/api-credential APIConnectivitySecurityCred

🔄Migration Guidance: Moving from APIAccess Plan to BTP CLI Security API Credentials

👉Why migrate?

✅APIAccess plan is deprecated/obsolete.
✅BTP CLI provides a centralized, secure, and role-based way to manage credentials.
✅Future enhancements will be delivered only for the BTP CLI approach.

👉Suggested migration approach:

Identify all applications, integrations, or scripts currently using credentials generated via APIAccess plan.
Recreate credentials using BTP CLI with the required Security Administrator role at the subaccount level.
Update configurations (destination services, API clients, pipelines, etc.) to consume the new credentials.
Decommission old credentials to avoid accidental usage.

📌Tip: Run this migration in a test subaccount first to validate all dependencies before rolling out in production.

🙋‍♂️ FAQs

Q1: Do I still need the Space Developer role for managing credentials?
👉No. Managing Security API Credentials requires the Security Administrator role at subaccount level, not CF space roles.

Q2: What happens if I continue using APIAccess plan?
👉APIAccess is obsolete. Existing instances may continue temporarily, but no future support or enhancements will be provided.

Q3: Can I automate credential rotation with BTP CLI?
👉Yes ✅. You can script credential creation/deletion via BTP CLI and integrate into CI/CD pipelines for automated rotations.

📚References

🚀 Introducing SCIM API for SAP Sales & Service Cloud v2: Seamless User Sync between Source & Target

2025-08-30T10:53:18.129000+02:00

Note : Please note that the SCIM feature is in General Availability.
https://api.sap.com/package/SAPSalesServiceCloudV2/rest

SAP Sales & Service Cloud v2 now supports SCIM (System for Cross-domain Identity Management) APIs, enabling seamless and secure user provisioning from SAP Identity Authentication Service (IAS) or Customer Identity Directory via SAP Identity Provisioning Service (IPS).

This integration simplifies identity lifecycle management, ensures compliance, and eliminates manual user creation in the target system (SAP Sales & Service Cloud v2).

SCIM API in SAP Sales & Service Cloud v2 is available by default.

SSC v2 SCIM API (Official API Documentation)

### Tenant Details but you need to pass the tenant id in the URL

GET {{SSCv2url}}/scim/v2/Users
Content-Type: application/scim+json
Authorization: Bearer {{accessToken}}



PUT {{SSCv2url}}/scim/v2/Users/<id>
Content-Type: application/scim+json
Authorization: Bearer {{accessToken}}

<payload of the user>


PATCH {{SSCv2url}}/scim/v2/Users/<id>
Content-Type: application/scim+json
Authorization: Bearer {{accessToken}}

<payload of the user>

🚫Important Notes to keep in mind before enabling:

No Manual User Creation Allowed

This ensures that all user data is centrally managed and synchronized, maintaining consistency and reducing the risk of identity mismatches or unauthorized access.

Once SCIM-based provisioning is enabled in SAP Sales & Service Cloud V2:

Manual user creation in SAP Sales & Service Cloud v2 is disabled.

When using IPS (SCIM 2.0 based API), only users of type Employee are provisioned. This version introduces an enhanced SCIM API that no longer requires SAP Cloud Integration. It supports patch operations and provisioning of application-specific groups(Business Roles). In addition to pagination using startIndex and count, cursor-based pagination is also supported.

Why SCIM API Matters

SCIM is an open standard designed to automate the exchange of user identity information between identity providers and service providers. With SCIM support in SAP Sales & Service Cloud v2, organizations can:

Automatically provision and de-provision users
Sync user attributes and roles
Ensure consistent identity governance
Reduce administrative overhead

Benefits of SCIM Integration

Automated User Lifecycle Management
Improved Security & Compliance
Centralized Identity Governance
Reduced Manual Effort
Scalable for Large Enterprises

Integration Flow: SAP IAS or Microsoft Active Directory to SAP Sales & Service Cloud v2

Below is the flow diagram illustrating how users are synced from Microsoft Active Directory or/both SAP Identity Authentication IAS to SAP Sales & Service Cloud v2 using IAS and IPS:

Flow Breakdown:

Microsoft Active Directory (AD): Acts as the source of truth for user identities.
SAP Identity Authentication Service (IAS): Connects to AD via LDAP or Azure AD and serves as the identity provider.
SAP Identity Provisioning Service (IPS): Pulls user data from IAS and pushes it to SAP Sales & Service Cloud v2 using SCIM APIs.
SAP Sales & Service Cloud v2: Receives user data via SCIM and provisions users automatically.

Identity Provisioning (IPS) Documentation - Target System

https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/target-sap-sales-cloud-and-sap-service-cloud

Final Thoughts

The introduction of SCIM API support in SAP Sales & Service Cloud v2 marks a significant step toward modern identity management. By leveraging IAS and IPS, organizations can streamline user provisioning, enhance security, and ensure a consistent user experience across systems.

CREATE AND ASSIGN AUTHORIZATION POLICIES IN IAS

2025-09-17T12:37:51.141000+02:00

Introduction

SAP Identity Authentication Services (IAS) provides secure access management for SAP cloud applications. One of the core features in IAS is Authorization Policies, which allow administrators to control access to applications and resources based on defined rules.

In this blog, we’ll go through the steps to create and assign authorization policies in IAS, ensuring only the right users have the right level of access.

Why Authorization Policies Matter

Control user access based on attributes like group, role, or user ID
Enforce compliance and security requirements
Provide flexibility for hybrid or multi-application scenarios
Simplify administration by centralizing access control in IAS

Please follow the step by step process to create authorization policies in IAS :

HOW THE IAS SUPER ADMIN CAN CREATE AND ASSIGN AUTHORIZATION POLICIES IN IAS

CREATION OF AUTHORIZATION POLICIES

This document tells you how you can assign the authorization policies or give admin access to Granular level to HR managing their own HR Organization and division. This will help to give granular access to HR admin in IAS by creating the authorization policies in IAS so that they can see only the employees belonging to their organization unit and reset the password for them.

We are creating the custom Policies for customers as we have different divisions and organization, and we would like to give access to the HR managers to their respective divisions accordingly.

The screen shots below are for your reference from the test system, and you can use the same step for production as well.

Prerequisite: You have SUPER ADMIN access to IAS tenants in which you are going to create the authorization policy.

IAS Tenants:

For Test: https://XXXXXXX.accounts.ondemand.com/admin/

Give the URL https://XXXXXXX.accounts.ondemand.com/admin/ in the browser and the below window will open.

Give your Email or Username and password to login to IAS an ADMIN and click on continue.

You will see the login screen of IAS as shown below:

Not go to the “Application Resources” and click on the tenant settings :

Here , you can go the policy-based authorization and enabled the option in the right context window.

Now go to the “Application Resources” section and click on the SuccessFactors application.

Click on the applications and it will show you the screen below.
Go the Administration console as shown below under the System Application. You can see below highlighted one:

Now you can see to the right-side pane of the screen with Authorization policies. Click on that and you will see the screen below.

Click on the create button and give a name for which you want to create a new policy. It will ask for the Policy name and the Base Policies. We have given a name as IMAS_AUT_USER as an example to show and giving access to Read the users and update the users’ details in IAS (Identity Authentication services).

Now click on the create button and it will take you to the screen below:

Here click on the + sign and it will take you to the screen below where you can choose the user. Division and assign the division according to the employee export file.

Choose for both the restrictions + Sign and choose user. division for both the places because we would like to give admin access to HR to see and update only the users belonging to those division.

13. Now we need to find the value from the SF export file as attached here to see what the value is coming from the SuccessFactors for the organization/division and use the exact same field value here.

PFA.

Check the column AS and field name custom06 value and use the same value in the above user.division field. In our case we have set up rules for AUT, so we need to filter column06 from the exported file from SF and search for AUT. We go custom06 value as AUT(AUT). This value needs to be updated in the user. Division value . ( Please note you need to fill this custom06 values from Successfactors to each user in IAS by using the source and target transformation) .

Source transformation code :

{

"sourcePath": "$['urn:ietf:params:scim:schemas:extension:successfactors:2.0:User']['customFields'][?(@.customFieldName == 'custom06')]['value']",

"targetPath": "$.custom06",

"optional": true

}

Target transformation code :

{

"sourcePath": "$.custom06",

"optional": true,

"targetPath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['division']"

}

The same value we need to update in the user. Division field as shown below.
At the end you can add the below authorization as well USE schemas.READ_SCIM_SCHEMAS click on ADD USE and select from the dropdown the authorization as USE schemas.READ_SCIM_SCHEMAS. This is also required READ_SCIM_SCHEMAS authorization policies. Otherwise, you won't be able to see and access the Export Users’ title.

Click on confirmation and it will be added.

First click on SAVE and then click on the Assignments tab and add the user you would like to give this authorization.

Assign/click on ADD to add the users whom you want to give granular authorization. Please note that the user should exist in the IAS User directory. Now I am giving access to one user for example Mohana@gmail.com

I can click on add and search the user using the email address and add the user. After that the user is assigned to the new authorization policy and the user can access the employees belongs to AUT organization.

Search for the user whom you want to give access to.

Click on the ADD. The user is added successfully.

The above steps complete the creation of the new Authorization policies and assignment of users.

HOW TO ASSING AUTHORIZATION TO HR ADMIN/ ANY USERS USING THE EXISTING AUTHORIZATION POLICIES

Follow the steps from 1 to 7 and complete the steps as mentioned above. ( The above example shows the process , now you want to assign other users in the same authorization policies)
Now you are in the authorization policies tab, and you need to click on the filter to easily access the custom packages created and choose the one required for you to be updated. Please note that IMSA_AUT_USER is the test Authorization policy. I have created many authorizations policy for each division, that is why you can see many customer packages but here I am assigning the user to only IMSA_AUT_USER authorization policy.

Click on the filter and choose customer packages.

Click ok to see all the customer packages filtered and you can choose the one required for you. I am choosing the IMSA_AUT_USER and would like to assign one existing user.

Now open the customer authorization policies named IMSA_AUT_USER. You can choose the package as per your requirements. I would like to give access to the below user for the authorization policies IMSA_AUT_USER.

You must click on the IMSA_AUT_USER authorization policy as shown in the above step. It will show you the screen below. Go to the assignments tab and assign/add the above user.

Click on the ADD and search for the user with username as BHR.

Now the user has assigned the authorization policies created by you. You can reset the password for this user in IAS and try to login and you will see that this user will be able to see only a few users who are belonging to the division AUT(AUT).

Please note : You must remove the user from Administrator group if it is assigned as an administrator otherwise the Administrator group in IAS under user & Authorizations->administrator will give more permissions to the administrator.

SAP GRC for SAP HANA - Early Adopter Care Program is Open!

2025-10-02T00:21:59.824000+02:00

Ready to Shape the Future of SAP GRC for SAP HANA?

The Early Adopter Care (EAC) Program for SAP GRC for SAP HANA (GRC 2026) is now open!

This is an opportunity to gain early access to SAP’s latest innovations in governance, risk, and compliance (GRC), which include:

SAP Access Control
SAP Process Control
SAP Risk Management
SAP Audit Management
SAP Business Integrity Screening
SAP Tax Compliance
SAP UI Data Protection Masking
SAP UI Data Protection Logging

As a participant, you’ll be among the first to implement and provide feedback on SAP GRC for SAP HANA before general availability.

This program is run in close collaboration with SAP experts, giving you direct access to development teams and dedicated support as you modernize compliance processes on SAP S/4HANA.

What’s in it for you?

Early access to SAP GRC for SAP HANA innovations
Close collaboration with SAP Development to minimize risks and safeguard projects
Dedicated feedback channel with product experts and project coaches
Visibility into who is adopting the newest GRC capabilities
Opportunity to influence the direction of future releases with your feedback

When is it happening and how to register?

Registration: October 1 - November 15, 2025
Program Start: March 9, 2026

Customers can apply directly on the Influence Platform and become part of a select group helping shape the future of SAP GRC capabilities.

Who should join?

This program is ideal for organizations:

Already running SAP GRC solutions and planning to transition to SAP GRC for SAP HANA
Looking to modernize governance, risk, and compliance processes on SAP S/4HANA

Why it matters

The Early Adopter Care Program is more than an early access, it’s a partnership. By joining, you’ll:

Shape SAP GRC for SAP HANA with your real-world use cases
Gain first-hand support from SAP’s development organization
Establish your organization as a thought leader in modern GRC adoption

Take the next step

Don’t miss the chance to be part of the future of SAP GRC. Join the Early Adopter Care Program today and secure your seat at the forefront of innovation.

Apply now via the Influence Platform.

Secure Your Digital Journey with SAP CIAM

2025-10-02T14:00:00.040000+02:00

Secure Your Digital Journey with SAP CIAM

Over the years, working in customer experience and digital technologies, I have witnessed the rapid evolution of both customers and the infrastructure needed to serve them. When you consider the “customer,” the need to understand who they are has become a central focus of the user experience. The world of digital identity has continuously adapted. Social logins once felt like the future—now, passwordless or passkey authentication is a requirement. Data privacy has shifted from an afterthought to a boardroom priority, largely driven by regulations like GDPR, CCPA, and others. What used to be considered "good enough" security no longer suffices, as becoming the subject of a data breach headline is a risk no company can afford..

Even my daughter now warns me not to share her identity online, as I don’t have her consent—proof that awareness of digital risks is becoming second nature to the next generation. In this new era, trust isn't a nice-to-have; it’s the foundation of every customer interaction.

That’s why Customer Identity and Access Management (CIAM) is a critical part of any modern digital strategy and future-forward IT landscape. When organizations get digital identity right, they unlock more than just security—they create better, more trusted customer experiences at every touchpoint.

Bridge the Gap Between Experience and Trust

In today's digital-first landscape, businesses must navigate the challenge of delivering seamless customer experiences while ensuring robust data protection—a balance that is crucial for building trust with increasingly privacy-conscious consumers. However, many organizations are stuck navigating data silos, which fragment customer insights and prevent a unified understanding of their audience.

SAP CIAM offers a comprehensive solution to these challenges by unifying data management, enhancing security frameworks, and simplifying privacy compliance. It empowers businesses to protect against threats, manage identities efficiently, and offer personalized user experiences that foster customer loyalty.

SAP CIAM overcomes the limitations of outdated systems and enables organizations to confidently:

Secure users

Reduce privacy concerns

Scale efficiently

Secure Users and Safeguard Data

Concerned about data breaches? SAP CIAM is engineered to protect your customer data and minimize security risks, building trust between you and your customers. By prioritizing robust threat detection and protection, this solution ensures your business remains secure, fostering loyalty and reinforcing customer confidence in sharing their data.

Access real-time password suggestions

Utilize built-in screen sets for password updates

Generate one-time passwords

Integrate with external identity services

Enable biometric sign-in for secure login

Harness AI risk-based authentication

For a deeper look at how SAP CIAM addresses today’s evolving security landscape, join us at SAP TechEd on November 6 for a dedicated CIAM security session. Register here to secure your spot and learn more.

Reduce Privacy Compliance Risk

Keeping up with evolving privacy regulations can be daunting. SAP CIAM simplifies these challenges through efficient consent management capabilities, enabling businesses to adhere to global standards like ISO, BSI, and SOC 2. With user-friendly self-service portals, SAP CIAM respects customer privacy while maintaining compliance—ultimately strengthening trusting relationships.

Capture consent across all channels

Customize for privacy policies and brand

Configure single sign-on (SSO)

Enable global access

Increase Efficiency at Scale

Worried about system overload during peak times? SAP CIAM effortlessly manages traffic spikes, supporting billions of unique identities and transactions monthly. This capability allows businesses to capitalize on each opportunity without technical setbacks or undue stress on IT teams. With 347 million active users across 85 thousand sites, SAP CIAM is a proven solution for large-scale digital operations.

Design and execute identity flows

Duplicate site configurations and settings

Offer OOTB, OIDC-compliant login experiences

Create identity screens with drag-and-drop

Elevate Your Identity Strategy with SAP CIAM

SAP CIAM empowers businesses to bolster their security measures, ensure data privacy compliance, and efficiently scale their digital operations. Additionally, it offers pre-configured connectivity with over 60 SAP products, including SAP Business Technology Platform, SAP S/4HANA, SAP Customer Experience solutions, and SAP cloud ERP solutions, enhancing integration across your enterprise.

Incorporating SAP CIAM into your digital strategy could be the next step toward elevating your business with enhanced security, data protection, and scalability.

Learn more here.

From Penalty to Power Play: Why Identity Management Is Key to Better Customer Experiences

2025-10-03T20:53:03.532000+02:00

A few weeks ago, a friend bought tickets to a hockey game and wanted to transfer them to me. Like many people, we went with the quickest workaround—she shared her login credentials so I could access the tickets. But what should have been a simple process turned into several days of password resets, missed messages, and back-and-forth. By the time I finally got into her account, the tickets were gone. She had attempted to transfer them during the delay, but amid the confusion and technical issues, I never actually received them. If I had been able to log in right away, I could have just downloaded them directly. But the access issues created confusion, and without any clear support from the platform, we ended up losing the tickets—and missing the game.

It was a simple plan that fell apart because of something as basic as account access.

This experience is a small example of a much larger issue in digital commerce: the friction that arises when identity management isn’t built with the customer in mind. It’s easy to overlook, but poor identity experiences lead directly to lost opportunities—not just for consumers, but for the businesses trying to reach them.

Identity Friction = Lost Revenue

In today’s commerce landscape, customer expectations are sky-high. If a login process is confusing, if an account is hard to access, or if personalization feels off—people walk away. And often, they don’t come back.

Poor identity experiences hurt businesses in more ways than one:

They interrupt the buying journey. Whether it’s a login loop, a forgotten password, or a complicated checkout flow, friction at these key points drives abandonment.
They block personalization. When customer data is fragmented across systems, it’s hard to deliver the tailored experiences that today’s buyers expect.
They erode trust. Without clear consent management and transparency, customers hesitate to share information—or stop engaging entirely.
They slow down growth. Outdated systems and homegrown solutions often can’t keep up with omnichannel strategies or evolving compliance needs.

For a deeper dive into how SAP CIAM can help reduce identity friction, join us at SAP TechEd on November 6 for a dedicated CIAM security session. Register here to secure your spot and learn more.

Where SAP CIAM + Commerce Cloud Make the Difference

Customer Identity and Access Management (CIAM) helps solve these challenges by making identity work for the customer—not against them. When integrated into your commerce ecosystem, CIAM doesn't just handle sign-ins—it actively supports better customer relationships and business outcomes.

Here’s how:

It reduces friction at every stage—from anonymous browsing to account creation to repeat purchases. The experience becomes smoother, simpler, and more secure.
It improves conversion by enabling personalized, real-time engagement without relying on clunky data handoffs or third-party cookies.
It builds trust by giving customers control over their data, preferences, and permissions—while helping businesses stay compliant across regions.
It supports scale by integrating identity across every digital touchpoint, enabling consistent experiences on web, mobile, in-store, and beyond.

In short, CIAM allows businesses to move away from fragmented, frustrating interactions and toward a unified customer experience that feels intuitive, safe, and relevant—every time. To hear firsthand how SAP customers are achieving this with SAP CIAM and Commerce Cloud, join us at SAP Connect in Las Vegas on October 8. Register here to attend.

The Takeaway

In commerce, moments of friction are more than just annoyances—they’re missed opportunities. Whether it’s lost hockey tickets or lost revenue, the cause is often the same: a broken identity experience.

Modern CIAM, especially when combined with a powerful commerce platform, turns identity into an asset. It streamlines the journey, protects the user, and empowers businesses to engage with clarity and confidence.

And the best part? It just works—so your customers don’t have to.

Learn more here.

Posting System-wide Messages Using "Manage News" App

2025-10-17T16:05:13.051000+02:00

Introduction

For long time SAP users, they enjoy the benefit of posting and reading a system related message in SAP ECC or SAP S/4HANA systems using transaction code /sm02. From 2508 Release, SAP Cloud ERP (formerly called SAP S/4HANA Cloud Public Edition) can do the same on My Home page. This blog discusses the details on how to create the messages called News Articles, especially how to make them visible to your intended audience.

Background

Until Release 2508, our customers can see a beautiful My Home page with display of software related news (see box in the below figure). The news is limited to SAP provided features in your subscribed function areas, such as Supply Chain, Human Resources, etc.

Software related News

Many users were asking if they can post their own news in the News section. This feature becomes available in Release 2508 so that an administrator (yes, only the user with SAP_BR_ADMINISTRATOR business role) can post relevant news to the users on a needed basis. Here is an example of news postings – Hot Fix Collection 6 is going to be applied this weekend.

News Article Postings

Recently I heard some users were attempting to post their own news without much success. I tried and figured out what is the mechanism behind and would explain them in detail in this blog.

News Article Creation

To create a News Article, we use the Manage News app. To launch this app, the user needs to have the business user role SAP_BR_ADMINISTRATOR, which contains the Business Catalog SAP_CORE_BC_CUX_NWS_MNG_PC.

When you launch the Manage News app for the first time, it should be empty, News Articles are 0, News Groups are 0 and News Images are 0.

Empty Entries in the Manage News app

Before discussing news article creation, let me explain some relevant components first.

News Images

Besides default images, customers can upload their own images to be used together with news articles. For example, I downloaded one system maintenance related image from SAP’s brand image library as below.

My Image for System Maintenance News Articles

By clicking on the News Images tab, and Create button, we can create a news image called “System Maintenance”.

News Image – System Maintenance

I also downloaded another blue Joule image to be used for Artificial Intelligence related news. In the News Images tab, you can see these two Image entries are created.

Two Image Entries in News Images Tab

News Groups

News Groups are used to group relevant news articles together and display under one umbrella. For example, I have two system related News Articles

System Upgrade 1 for Release 2602 Upgrade
System Upgrade 2 for HFC 1 Upgrade

Since they are all System Maintenance related news, I put them under the same System Maintenance Group. When you check the News, you can see System Maintenance related news are all grouped together.

System Maintenance Group News

When you click on the News screen “System Maintenance”, a second window pops-up. It lists three news

Critical: System Upgrade 2
Critical: System Upgrade 1
Normal: Caution: Business Catalogs

Three News Articles within the System Maintenance News Group

The sequence of this group of news is most probably based on creation time. The newly created news is on top.

In addition, one news article can belong to more than one news groups. That is the case of News Article Caution: Business Catalogs. It belongs to two News Groups: “AI Joule Group” and “System Maintenance”. I will discuss that further later.

The creation of a News Group is quite straightforward as shown below. You can also assign an image to a News Group. This image will supersede any images assigned to a news article.

System Maintenance News Group

When you leave the Description section blank, the system will display a default message for you as shown below: Discover new features and changes of this release.

Default News Group Description

News Article

Now let’s create our first News Article: System Upgrade 1 as shown below. It is a created News Article with a background image (Blue Joule). You can further Edit it or Delete it.

System Upgrade News Article

Overall, the creation is quite straightforward. I only explain a few entries:

Title and Subtitle is a combination. You need to make it eye catching for users.
Footer Text could indicate its author; at least that’s how I use it.
Background Image is optional, but a good picture saves thousands of words. However, if this news article is under a News Group umbrella, the image won’t show when you display the news.
Publish Start is tricky. If you want to see the News Article right away to verify your news, you could put a yesterday’s date here. Otherwise, you can put your intended publish time.
Status: as soon you click the Create button, it changes from Draft to Published.
News App Assignment is for limiting the news exposure by applications. For example, if the news is only intended for users of certain applications, such as Manage Workforce, you create a Manage Workforce app entry. With that, the news is only displayed to those users with access to the Manage Workforce app.
News Group Assignment allows you to assign more than one group. With that your news article will appear in each News Group when you click on the News section. For example, this System Upgrade 1 news article will appear not only in System Maintenance Group, but also in AI Joule Group as shown below.

The System Upgrade 1 News Article Displayed under AI Joule Group

When you create a news article without assigning a News Group, this news article will appear as an independent (vs. belonging to a news group) entry in News section. For example, I have one news article called “System Announcement” which does not belong to any news groups. It will show by itself.

A News Article without a News GroupHere you probably noticed the background image is a glass dome. That is the default image by the system because I didn't assign a background image to this news article.

News Display

When I first worked on Manage News app, I could not see my news articles in News Section. I found out the business catalog SAP_CORE_BC_CUX_NWS_DSP_PC must be assigned to the users for them to see the News. This is not documented anywhere!

Let’s check this business catalog out in the Business Catalogs app. It only serves one Fiori application, the Display News app.

Business Catalog of SAP_CORE_BC_CUX_NWS_DSP_PC

By expanding above screen to include Used in Business Role Templates tab, I found it is used in SAP_BR_EMPLOYEE business role template. Our developer probably thinks all users should have the role of SAP_BR_EMPLOYEE. Therefore, displaying news is not a problem. This might not be the case. Because this business role introduces a lot of Employee Self-Service apps, not necessarily adopted by all our customers.

My advice is to create a user defined business role like Z_Display_News_All_Employee which contains one business catalog SAP_CORE_BC_CUX_NWS_DSP_PC; then you assign all users to this role. There is no need to assign a space or a page to the role. You can transport this user defined role to your Test and Production tenants (Note: I created this blog related objects in a production tenant to limit the impact to others; you usually do this in your Dev tenant).

With the proper business catalog SAP_CORE_BC_CUX_NWS_DSP_PC assigned, I can see the News in my Fiori Launchpad – My Home – News.

Four News Groups Are on Display

Updates

1/16/2026: With 2602 Release, there is a "Required Reading" button. With that option on, the user has to read and acknowledge the news.

This mandatory news is displayed when a user logs on to the system as shown below.

Conclusion

With the above explanations, you should be able to create a news article or a group of news articles as an administrator and view them as a business user. The Manage News app is a powerful tool to keep your users informed on your SAP Cloud ERP system.

Reference

SAP Help: Manage News
Blog: User Management in a Nutshell for the SAP S/4HANA Cloud, public edition

Update History:

1/16/2026: Added Updates section before Conclusion.

Identity and Access Management with Microsoft Entra, Part III: SuccessFactors and Role Provisioning

2025-10-20T10:05:47.788000+02:00

Part II of this blog series took a technical deep-dive into a hybrid scenario for managing identities and their access across SAP Business Technology Platform (BTP) and S/4HANA on-premise. Part III enhances the scenario by introducing SAP SuccessFactors (SF) as the source for employee and user data, and leverages the new capabilities in Entra for SCIM-based provisioning to SAP Cloud Identity Service (CIS) supporting groups to streamline end-to-end role assignments in the connected SAP ABAP backend.

Scenario Overview

Part III introduces substantial changes and enhancements to the scenario in part II:

Microsoft Entra and Active Directory (AD) were the primary and authoritative systems (aka "source of authority", SOA) for identity data in part II. For many organizations, however, the trusted SOA for identities is a Human Resource Information System (HRIS) such as SAP SuccessFactors (SF), which will be added to the scenario in this part, and where new employees are now onboarded.
Identity creation, updates, and deprovisioning are now driven by HR events (e.g., hiring, role changes, terminations) from SF. AD and Entra become downstream provisioning targets in this scenario. Because users require access to SAP from SAP GUI on their corporate AD domain-joined workstation using Kerberos/SNC-based single sign-on (SSO, see part II), the solution architecture in this scenario integrates SF with the SAP SuccessFactors to Active Directory user provisioning connector from the Microsoft Entra App Gallery. This pre-built, cloud-based solution supports inbound- or HR-driven provisioning of new employees from SF to AD through Entra. New users provisioned to AD by this connector will be synchronized to Entra with the existing setup of the Microsoft Entra Cloud Sync Provisioning Agent from part II of this blog series that runs on the Domain Controller (DC) in our fictitious company BestRun's corporate network.
Part II focused on the automation of provisioning the user's identity data. The user's authorization in the SAP backend (we used role SAP_BC_ABAP_DEVELOPER_5 as an example) was still managed manually by assigning the user to the equally named group "SAP_BC_ABAP_DEVELOPER_5" in the CIS tenant (see step 10.20 in part II). Also the group in CIS had to be created manually in the previous part of the scenario (see steps 9.17-9.19). This approach may work for a few backend authorizations, but won't scale for a larger number of connected systems and applications with complex authorization models. A key objective in this scenario is to fully automate end-to-end provisioning and deprovisioning of the user's authorizations, which includes the synchronization of backend roles and their corresponding groups in CIS and Entra, as well as the memberships of users to these groups, that ultimately assigns them to the backend roles. The updated version of the SAP CIS connector from the Microsoft Entra App Galley now enables automated provisioning of groups and their entitlements as memberships from Entra to CIS. This new feature in the SCIM (System for Cross-domain Identity Management, IETF RFCs 7642, 7643 and 7644)-compliant outbound provisioning connector in Entra streamlines the end-to-end lifecycle management for authorizations in the scenario. By assigning the new user to a group representing the PFCG role in the SAP ABAP system, this group and the user's membership are now also automatically provisioned to CIS, and from there to the backend system. Similar to part II, the group in Entra and CIS is mapped to the PFCG role by using the same name.

Figure 1 illustrates the SOA for the IAM entities in the scenario:

Figure 1

Although SOA for identity data moves to SF, the connected SAP system remains the authority for the definition of the roles that can be assigned in the scenario. Managing the actual assignment of users to these roles through access packages and approval workflows remains the responsibility of Entra ID Governance. With no single SOA for users, groups and roles centralized at one place in the system landscape, figure 2 shows the updated and newly introduced system components based on the existing setup from part II, and illustrates the steps of the provisioning flow for a new onboarded employee requesting access to a role in the corporate SAP system:

Figure 2

CIS is responsible to integrate the connected SAP systems following this reference architecture. It synchronizes the role from the backend (SAP_BC_EPM_DEMO in this scenario) with the SAP Application Server ABAP connector configured as a Source System in BestRun's CIS tenant Identity Provisioning Service (IPS) which results in creating a group with the same name in the tenant's local directory. Connectivity from CIS to the SAP system on-premises remains unchanged from part II and is established via the connectivity service in BTP and the SAP Cloud Connector deployed in the corporate network.
CIS also takes care for creating the group in Entra by provisioning it with the Entra ID connector configured as a target system in the CIS tenant. This connector uses the Microsoft Graph API to manage groups in Entra.
The HR admin adds a new employee record in SF for the user in the sceanrio, Linda Larson.
The SAP SuccessFactors to Active Directory user provisioning connector picks up the new employee record by calling the SF Employee Central OData API endpoints to query for new or updated data.
The connector then provisions a user account for the new employee Linda in BestRun's corporate AD via Entra Cloud Sync and the Entra Provisioning Agent on the DC.
With Entra Cloud Sync configured in part II to synchronize AD with the Entra tenant, the new account in the corporate AD is also provisioned to BestRun's Entra ID tenant.
Linda starts a request for the SAP EPM access package with the MyAccess portal. For this initial login to Entra, Linda can use the self-service password reset (SSPR) feature in Entra to set her new Entra user account's password. With password writeback enabled in Entra Cloud Sync and SSPR to use password writeback, Linda's initial password reset or any future changes of her password are synchronized back to BestRun's on-premises AD as well. By completing the request, Linda is assigned to the access package resources, and becomes a member in the SAP_BC_EPM_DEMO group in Entra. To keep things simple, the access package policy requires no approval steps in this scenario.
The SAP CIS connector enterprise app is configured to perform all operations (create/update/delete) on new or existing user objects, but to skip creation on groups. Otherwise, Entra would try to create the same group again in CIS that has already been created in step 1, which would result in a naming conflict. Instead, it creates a new user account for Linda in CIS, but only updates her membership to the SAP_BC_EPM_DEMO group in BestRun's CIS tenant.
In addition to the new support for groups in the new version of the SAP CIS connector, authentication to CIS no longer uses basic authentication that sends static credentials with every request. Instead, short‑lived tokens with scoped, limited privileges using the OAuth 2.0 client credentials grant flow enhance security over basic authentication.
Provisioning to the SAP backend with the already existing SAP Application Server ABAP connector configured as a Target System in IPS starts by reading the new user and her group membership from the CIS tenant's local directory, and creating the new user in SAP as well as assigning this user to the corresponding SAP_BC_EPM_DEMO role.
Finally, Linda can login to BestRun's corporate AD from her workstation, obtains a Kerberos token from the DC, and uses it to securely single sign-on to the backend from SAP GUI and the SAP Secure Login Client. This requires mapping of her user principal name (UPN) in AD to her SAP user, which has already been configured in the mappings of the SAP CIS connector in Entra (see step 6.18 in part II) and the transformation of the SAP Application Server ABAP target system in IPS (see step 9.12 in part II).

If you want to see the scenario in action, tune into the recording from our latest online session (in german language) with the DSAG TG "SAP IAM Strategie mit Microsoft" from October 7th, or check out episode 263 from @Holger-Bruchelt SAP on Azure video podcast.

Prerequisites and lab setup

You can continue to use all subscriptions, systems and tenants from your lab in part II, because all prerequisites also apply for this scenario. In addition, make sure that you meet the following prerequisites to successfully implement the enhanced scope of this scenario:

Administrative access to an SF instance with permissions to setup provisioning credentials and onboard new employees.
An SCI tenant in a matching region of your BTP subaccount for on-premise connectivity that has Microsoft Entra ID as a target system enabled.
An Entra ID tenant with self-service password reset (SSPR) enabled and Entra Connect cloud sync configured for SSPR writeback to the AD in the scenario.
Re-run steps 9.1 to 9.10 of part II in your CIS tenatn with the updated file LocalDirectory.json for the LocalDirectory source system, and the updated file SAPA4H_IPS.json for the SAPA4H target system. The updated files apply minor changes to the transformations of both systems based on valuable feedback in the comments to part II. The customAttributes are no longer used to carry over the values for the SAP user name and SNC mapping from Entra to CIS. Instead, the extension attribute sapUserName is used, and construction of the SNC mapping has moved from Entra to the transformation of the SAPA4H target systems (lines 13 to 28).

Note 📢📢📢

This tutorial extends and updates the scenario from part II. Any components and their configurations that are not added or changed in this scenario, such as the SAP Cloud Connector or Active Directory, are not covered in this tutorial. If you arrived here and have not completed part II, please do so first, and then come back again.

As before, supporting files for this tutorial can be found in the blog series GitHub repository. Now let's get started with setting up the provisioning of new employees from SAP SuccessFactors to Entra.

Create API User in SuccessFactors for provisioning to Entra

Calling the SF OData APIs from both SF connector apps (Entra & AD) requires an API User in your SF instance who has the appropriate permissions to retrieve the required entities and their attributes.

Step	Description	Screenshot
1.1	Login to your SF instance as a system administrator who has access to the Admin Center.
1.2	Enter Import Employee Data in the search bar and select the action from the search results.
1.3	Select Basic Import from the entity drop-down list. Click Browse...
1.4	Open the CSV file to import the API user from the GitHub repo.
1.5	Click Validate Import File Data.
1.6	Check for the Validation Successful message. Click Import.
1.7	Wait for the confirmation message that the file has been uploaded and is being processed.
1.8	Enter Manage Permission Roles in the search bar and select the action from the search results.
1.9	Click Create.
1.10	Enter Entra Provisioning Role as the Name for the new Permission Role that will be assigned to the imported API user. Keep the default value Employee for User Type, and click Next.
1.11	On the Add Permissions step in the Create Role wizard, enter Manage Integration Tools in the search bar and click the lens icon. Activate the checkbox for Allow Admin to Access OData API throuch Basic Authentication.
1.12	Enter Employee Central API in the search bar and click the lens icon. Activate the following checkboxes: Employee Central Foundation OData API (read-only) Employee Central HRIS OData API (read-only) Employee Central Foundation OData API (editable) Employee Central HRIS OData API (editable)
1.13	Enter Employee Data in the search bar and click the lens icon. Scroll to the User Information section and activate the View checkbox for all attributes.
1.14	Scroll down to the HR Information section and active the View checkbox for all attributes.
1.15	Scroll down to the Employment Details section and activate the View checkbox for all attributes. Click Next.
1.16	Click Save.
1.17	Click Not Now.
1.18	In the search bar, enter Manage Permission Groups and select the action from the search results.
1.19	Click Create New.
1.20	Enter Entra Provisioning Group for the Group Name of the new permission group. Add the imported API user to the new group by selecting User Type Employee. Select User from the People Pool drop down list. Select = (equal to) as the search operation, and enter Entra as the value. Select the imported API user record entra entra provisioning from the value help. Click Done.
1.21	Click Done.
1.22	In the search bar, enter Manage Permission Roles and select the action from the search results.
1.23	From the list of permission roles, click on the Add Role Assignment action for the new Entra Permission Role.
1.24	Keep the default values on the Basic information tab. Click Next.
1.25	Select the From groups option. Click Select Groups.
1.26	Activate the checkbox for the new Entra Provisioning Group. Click Select.
1.27	Click Next.
1.28	Keep the default values on the Define a Target Population step and click Next. Keep the default values on the Define Data Blocking step and click Next. On the Preview step, click Save.
1.29	Enter Reset User Passwords in the search bar and select the action from the results list.
1.30	In the Username field, enter entra_provisioning_user. Select the imported API user entra_provisioning_user (entra entra provisioning) from the value help.
1.31	Select the user in the result list. Enter the same value for the password in the New Password and Confirm Password field. Click Reset User Password.
1.32	The confirmation that the password has been resetted is shown.

Setup provisioning from SuccessFactors to Active Directory

The new API user's credentials are now being used to setup the SAP SuccessFactors connector for provisioning new employees to BestRun's corporate AD. This ensures that every employee managed in SF also gets a user account in AD which is required for SSO via SNC and Kerberos when accessing BestRun's SAP system(s) from a corporate AD domain-joined workstation.

Step	Description	Screenshot
2.1	Login with your Microsoft Entra tenant administrator to the Entra admin center with an additional URL query parameter Microsoft_AAD_Connect_Provisioning_ forceSchemaEditorEnabled set to true: https://entra.microsoft.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true. Select Enterprise apps from the Entra tenant's main navigation menu. Click New application.
2.2	Enter SuccessFactors to in the search bar. Click the tile with label SuccessFactors to Active Directory User Provisioning.
2.3	Enter a name for the new enteprise app (for example SuccessFactors to Active Directory User Provisioning <your SF instance company ID>). Click Create.
2.4	Select Provisioning from the navigation menu of the newly created enterprise app.
2.5	For the configuration settings in the next step, the distinguished name (DN) of the path in AD where new users should be created is required. You can either create a new container in AD for the onboarded employees from SF, or use an existing one. The screenshot shows the Active Directory Users and Computers tool with the default Users container selected and its properties dialog opened. From the tab Attribute Editor, the attribute distinguishedName is selected, and its value CN=Users,DC=corp,DC=bestrun,DC=com copied for the configuration of the following step (note that the DC (domain) components in your lab setup may be different.).
2.6	Select Provisioning from the navigation menu and expand the Admin Credentials section. Enter the following values: Tenant URL: Provide the tenant URL of your SF instance's API server which can be looked-up here. Note: Do not add the URL scheme (https://) to the value, but only the hostname. Default OU for New Users: Paste the value from the previous step, or enter any path in your corporate AD where you want new users to be created. Active Directory Domain: Select the domain from the drop-down box that your Entra Connect Sync agent is configured for. Admin Password: The vlaue you entered when resetting the new API user's password in step 1.31 Admin Username: The name of the imported user in step 1.4 (entra_provisioning_user), followed by the @-sign and the company ID of your SF instance. Click Test Connection.
2.7	Wait for the confirmation that the values could be successfully verified. Testing the connection also checks that the permissions of the provided API user are correctly set in the SF instance. Click Save.
2.8	Expand the Mappings section. Click Provision SuccessFactors Users.
2.9	By default, all employee records in the connected SF instance will be synchronized to Entra once provisioning is started. For testing purposes of this scenario you will restrict provisioning to the test user only. Click All records.
2.10	Click Add new filter group.
2.11	Enter the following value for the new filter group: Source attribute: personIdExternal Operator: EQUALS Clause value: llarson For the new Scoping Filter Title, enter Filter for llarson. Click Apply.
2.12	Click Apply.
2.13	For the userPrincipalName attribute mapping, click Edit.
2.14	Change the expression from [personIdExternal] to Join("@", [personIdExternal], "corp.bestrun.com") Replace "corp.bestrun.com" with your AD domain name. Click Ok.
2.15	Click Save and confirm with Yes.
2.16	Close the Attribute Mapping dialog box.

Setup users and groups provisioning to SAP CIS in Entra

To use the new features for groups provisioning and OAuth-based authentication in the SCIM-based SAP CIS provisioning connector, a new enterprise application will be created. You may want to remove the CIS enterprise app created in steps 6.1 to 6.23 of part II.

Step	Description	Screenshot
3.1	Select Enterprise apps from the Entra tenant's main navigation menu. Click New application.
3.2	Enter SAP Cloud Identity in the search bar. Click on the tile with the label SAP Cloud Identity Services.
3.3	Provide name for the new instance, for example SAP Cloud Identity Service (<your CIS tenant id>). Click Create.
3.4	Back on the Overview page, click the Provision User Accounts tile.
3.5	Switch the Provisioning Mode from Manual to Automatic. Expand the Admin Credentials section and enter the following values: Authentication Method: OAuth2 Client Credentials Grant Tenant URL: Provide the SCIM endpoint URL of your CIS tenant, for example https://<your tenant id>.accounts.ondemand.com/scim Token Endpoint: The OAuth token endpoint URL of your CIS tenant (for example https://<your tenant id>.accounts.ondemand.com/oauth2/token). You can lookup the token endpoint in your CIS tenant's admin console by navigating to Applications and Resource -> Tenant settings -> Single Sign-On -> OpenID Connect Configuration. Client Credentials: Enter the value for Client ID captured in step 4.7 of part II. Client Secret: Enter the value for Client secret captured in step 4.7 of part II. Click Test Connection.
3.6	Wait for the confirmation that the configuration has been tested successfully. Click Save.
3.7	Next, adjust the mappings to add the user's on-premise principal name as the SAP user name. Expand the Mappings section. Click Provision Microsoft Entra ID Users.
3.8	Activate the checkbox Show advanced options. By accessing the Microsoft Entra Admin Center with the addition URL query parameter in step 2.1, the additional option to edit the attributes for Entra appears in the Supported Attributes section. Click Edit attribute list for Microsoft Entra ID.
3.9	Scroll down to the last row in the table and enter onPremisesUserPrincipalName in the attribute name field. Click Save, and confirm with Yes.
3.10	Click Edit attribute list for SAP Cloud Identity Services.
3.11	Scroll down to the last row in the table and enter urn:ietf:params:scim:schemas:extension:sap: 2.0:User:sapUserName in the attribute name field. Click Save, and confirm with Yes.
3.12	Click Add New Mapping.
3.13	Select "Expression" for Mapping type. The Entra attribute "onPremisesUserPrincipalName" added in step 3.9 has the format "<Windows user name>@<Kerberos realm name>". The SAP login name should be equal to the Windows user name that can be considered unique across all users in the organization. The following expression extracts the Windows user name from the "onPremisesUserPrincipalName" and converts it to upper case for the SAP login name: Item(Split([onPremisesUserPrincipalName], "@"), 1) Enter this string for the Expression. As the Target attribute, select "urn:ietf:params:scim:schemas:extension:sap: 2.0:User:sapUserName" from the list. Click Ok.
3.14	Click Save.

Configure permissions in Entra for provisioning of groups from CIS

CIS provisions the groups (representing the PFCG roles in the SAP backend) with the Graph API to Entra. The required permissions to do so are configured in this step in the application registration created as part of the enterprise app for CIS.

Step	Description	Screenshot
4.1	From the navigation menu, select App registrations. On the All applications tab, search for the name of your enterprise app chosen in step 3.3, for example SAP Cloud Identity Services (<tenant id>). Select the application registration for the CIS enterprise app from the search results.
4.2	Select Certificates & Secrets from the navigation menu. Switch to the Client secrets tab. Click New client secret.
4.3	Enter a description for the new secret, for example Entra Provisioning and select an expiration period. Click Add.
4.4	Copy the value of the new secret to the clipboard and paste it to a temporary text file. It will be used in a later step.
4.5	Select API permissions from the navigation menu. Click Add a permission.
4.6	From the Microsoft APIs, click on the Microsoft Graph tile.
4.7	CIS calls the Graph APIs on its own behalf, and not on-behalf-of a signed-in user. Therefore, select Application permissions. In the search bar, start typing Group.ReadWrite. From the result list, activate the checkbox for the permission Group.ReadWrite.All. Click Add permissions. 📢Note: To follow the least privilege principle, only the permissions required for this scenario are added. Although CIS can also provision users to Entra, which would require an additional Graph API permission, we do not use this feature, and therefore only add the permission to manage groups.
4.8	To approve the new permission, provide the required admin consent by clicking Grant admin consent for <your tenant domain>.
4.9	Select Overview from the navigation menu. Copy the Application (client) ID to the clipboard, and paste it to the temporary text file where you've already kept the secret value.
4.10	Click Endpoints.
4.11	Copy the OAuth 2.0 token endpoint (v1) to the clipboard and paste it to the temporary text file where you've already kept the other configuration values.

Add SAP as source system in IPS

Now it is time to configure the additional source system in IPS for reading roles from the backend and create the groups from them in the tenant's local directory.

Step	Description	Screenshot
5.1	Login as the CIS administrator to your CIS tenant's admin console at https://<tenantID>.accounts.ondemand.com/admin. From the Identity Provisioning menu, select Source Systems.
5.2	Click Add.
5.3	You will create the new source system from a file, which can be found in the tutorial series GitHub repository. Click Browse... and open the file SAP A4H Source System.json from the file dialog. Click Save.
5.4	Switch to the Transformations tab to review the configuration. Only roles are read from the SAP Application Server ABAP and created as groups in CIS. Reading users from ABAP has been removed from the transformation settings, because Entra is the SOA for them in this scenario.
5.5	Switch to the Properties tab. For testing purposes, the abap.role.name.filter property is set on the source system to only read roles starting with the string SAP_BC_EPM.

Add Entra tenant as target system in IPS

Step	Description	Screenshot
6.1	Select Target Systems from the Identity Provisioning menu.
6.2	Click Add.
6.3	Click Browse... and select the file Entra ID Target System.json from the GitHub repository. Switch to the Properties tab.
6.4	Paste the values from your temporary text file into the following properties: OAuth2TokenServiceURL: Value for the OAuth 2.0 token endpoint (v1) copied in step 4.11 Password: Value for the secret copied in step 4.4 User: Value for the Application (client) ID copied in step 4.9 Click Save.
6.5	Switch to the Transformations tab to review the imported configuration. Similar to the new source system, the target systems also only provisions groups to Entra. Users have been removed from the default transformation.

Provision the PFCG roles as groups to Entra

To continue with the configuration in Entra ID Governance for the SAP EPM access package which includes the SAP_BC_EPM_DEMO, this group must be provisioned first from the SAP system via CIS to Entra. With the configuration of the new source and target system in CIS, you can start this initial provisioning.

Step	Description	Screenshot
7.1	Select Source Systems from the Identity Provisioning menu. From the list of Customer Managed source systems, select the SAP A4H source system. Switch to the Jobs tab.
7.2	Click Run Now for the Read Job type.
7.3	Select Provisioning Logs from the Identity Provisioning menu.
7.4	Select the first job for the SAP A4H source system from the list to view the execution logs.
7.5	After the job has finished, check the job log statistics. You can see the number of roles read from the source system SAP A4H and the same number of groups written to (created in) Entra ID.

Create the SAP EPM Access Package

The following steps guide you through the process of creating the SAP EPM access package that will contain the previously provisioned SAP_BC_EPM_DEMO group.

Step	Description	Screenshot
8.1	Go back to the Entra admin center. Expand the ID Governance section and select Entitlement management from the navigation menu. Select Access packages from the submenu.
8.2	Click New access package.
8.3	Enter SAP EPM for the name, and provide a description, for example Access to SAP Enterprise Procurement Model demo app. Click Next: Resource roles.
8.4	Click Groups and Teams.
8.5	Activate the checkbox See all Group and Team(s) not in the 'General' catalog. Enter SAP_BC_EPM in the search field and activate the checkbox for the SAP_BC_EPM_DEMO group. Click Select.
8.6	From the Role drop-down box, select Member. Click Next: Requests
8.7	Select For users in your directory from the Users who can request access options. Select All members (excluding guests). Set Require approval to No. Click Next: Requestor information.
8.8	Click Next: Lifecycle. Choose Never from the Access package assignments expire options. Set User can request specific timeline to No. Click Next: Rules.
8.9	Click Next: Review + Create. Click Create.
8.10	Copy from the newly created access package the link to the My Access portal and paste it to a temporary text file.

Onboard the new employee in SuccessFactors

As the HR admin, go back to SuccessFactors and onboard the new employee Linda Larson.

Step	Description	Screenshot
9.1	In the search bar, start typing Add new employee and select the action from the search results.
9.2	In the Identity section, leave the default Hire Date (today), select a Company and Event Reason (for example New Hire) from the list. Enter the following Name information: First Name: Linda Last Name: Larson Display Name: Linda Larson In Employee Information, enter llarson for the Person Id. Click Continue.
9.3	Keep the default settings in Personal information and click Continue.
9.4	In Job information, select a Job Classification from the list. Click Continue.
9.5	Click Submit.
9.6	Click View Profile of Linda Larson.
9.7	The profile of the new onboarded employee is shown.

Provision the new employee to AD and Entra

Next, you will provision the new employee to AD with the enterprise app configured for SuccessFactors in steps 1 ff. From there, an account in Entra gets created with Cloud Sync, and an alternative e-mail address is set by the administrator. This is required for the self-service password reset when the new onboarded user logs-in for the first time in the next section. We'll explore more sophisticated mechanisms for the employee onboarding process and initial login experience with Entra ID Governance lifecycle workflows in one of the next parts of this blog series.

Step	Description	Screenshot
10.1	Select Enterprise apps from the navigation menu. In the search field, enter the name of your SuccessFactors app created in step 2.3. Select the app from the search results list.
10.2	Select Provisioning from the app's menu.
10.3	Select Provisioning on demand from the menu. Enter the new employees personId from step 9.2 in the Select a user field. Click Provision.
10.4	The new employee's user account gets created in AD and the results are shown. Click Close.
10.5	On your DC, open the Active Directory Users and Computers (ADUC) tool. Navigate to the path where you provision new users from SF to (as configured in step 2.6). Search for the new user and open the Properties for it.
10.6	Switch to the Attribute Editor tab. Search for the distinguishedName attribute. Click View.
10.7	Copy the value of the attribute to the clipboard.
10.8	Go back to the Entra admin center and select Entra Connect from the top navigation menu.
10.9	Select Cloud Sync.
10.10	Click on your AD to Microsoft Entra ID configuration from the list.
10.11	Select Provision on demand from the menu. Paste the new AD user's distinguished name attribute value from the clipboard into the Enter a user field. Click Provison.
10.12	Entra will search for the user in AD, create the new account, and display the results. Click Close.
10.13	From the top navigation menu, select Users. Search for the new user by entering its user name. Select the new user from the list.
10.14	Click Edit properties.
10.15	Switch to the Contact Information tab. Click Add or edit other emails.
10.16	Enter an email address in the field that you have access to for testing purposes. This must not be the new users primary email address. Click Save.
10.17	Click Save.

Request the SAP EPM access package

Before making the request for the SAP EPM access package, the new employee Linda Larson has to (re)set her password in Entra using the self-service password reset in Entra ID. and subsequentely also for her user account in AD with the SSPR password writeback option enabled as listed in the prerequisites section of this tutorial.

Step	Description	Screenshot
11.1	Open a new private browser window. Open the URL to the My Access portal copied in step 8.10. On the login page, enter your new employees login name or primary email address. Click Next. Select the Forgot my password link.
11.2	Enter the character and numbers as shown in CAPTCHA. Click Next.
11.3	Select the I forgot my password option. Click Next.
11.4	Click Email to send a verification code to your alternative email address provided in step 10.16.
11.5	Open the inbox of your alternative email address. You should have received an email with the verification code. Copy the code to the clipboard.
11.6	Paste the code in the entry field. Click Next.
11.7	Enter your new (initial) password. Click Finish.
11.8	Wait for the password reset confirmation. Select the click here link.
11.9	Enter your username and click Next.
11.10	Enter your new password. Click Sign in.
11.11	Click Next.
11.12	For testing purposes, click Skip setup for now.
11.13	The request for the SAP EPM access package is started. Click Continue.
11.14	Optionally provide a business justification for the new request. Click Submit request.
11.15	In the Entra admin center, select Groups from the top navigation menu. On the Overview page, enter the test group's name SAP_BC_EPM_DEMO in the search field. Select the group from the search results list.
11.16	Select Members from the group navigation menu. By requesting the access package and auto-approving it, Linda Larson became now a member of this group.

Provision the group membership to CIS

Let's see the updated SCIM connector with support for groups in action, and provision Linda's new user account and her membership to the SAP_BC_EPM_DEMO to your CIS tenant's local directory. Since the group hasn't been created in CIS when your ran the initial load of the PFCG roles to Entra in steps 7.1 ff, the group will be provisioned as well.

Step	Description	Screenshot
12.1	Select Enterprise apps from the top navigation menu. Search for your CIS tenant's enterprise app and select if from the search results.
12.2	Select Provisioning from the app's menu.
12.3	Before provisioning the group and its members to CIS, it must be assigned to the app. Select Users and groups.
12.4	Click None Selected.
12.5	In the Search field, enter the group's name SAP_BC_EPM_DEMO. Activate the checkbox for the group in the search results and click Select.
12.6	Click Assign.
12.7	Select Provision on demand from the menu. In the Selected group field, enter the group's name SAP_BC_EPM_DEMO. Keep the default choice View members only, select the user from the members drop-down list by activating the checkbox for Linda Larson. Click Provision.
12.8	The results of the provisioning action are shown. On the Group details tab, you can see that the group SAP_BC_EPM_DEMO was created in your CIS tenant. Switch to the Group membership operations tab.
12.9	Linda's membership was also added successfully to the new group in CIS. Switch to the User operations tab.
12.10	A new user account for Linda was also created in the CIS tenant. Click View details.
12.11	Linda's new user account in CIS has been created with the attribute values according to the mapping configuration customized in steps 3.7 to 3.13. The last line shows the new sapUserName attribute set with Linda's on-premise user name in AD.

Provision the role assignment to SAP

Final step: Let's provision Linda's new user and her group membership in CIS to the SAP backend system.

Step	Description	Screenshot
13.1	Go back to your CIS tenant's administration console. Select Groups from the Users & Authorizations menu. Select the newly created group SAP_BC_EPM_DEMO from the list and check that Linda's user has been added successfully as a member. Next, select Source Systems from the Identity Provisioning menu.
13.2	Select the LocalDirectory source system from the list. Make sure that you've recreated this source system with the new import file from this tutorials GitHub repository path as mentioned in the prerequisites section. Switch to the Jobs tab. Click Run Now.
13.3	Select Provisioning Logs from the Identity Provisioning menu. Wait for the Status to Finish Successfully and then select the top log entry for your LocalDirectory source system.
13-4	In the Statistics of the provisioning action you can see that a new user was created in the SAP system, and that the equally named role for the group has been updated with Linda's membership.
13.5	Check the new role assignment in the SAP system and Linda's correct SNC mapping for Kerberos-based SSO by logging into the domain-joined workstation. To login, use the password that you've (re)set in step 11.7 and that has been written back to AD.
13.6	Start SAP GUI. You may need to add the connection to the SAP backend as described in step 10.29 and 10.30 in part II. Right-click on the connection and select SNC Login with Single Sign-On.
13.7	Because this is the first login for the new user you are prompted to either reset the initial password, or deactivate it. Click on Delete to use SNC and Kerberos-based SSO.
13.8	You are single signed-on to the SAP system using SNC and Kerberos SSO, and Linda's user menu shows the entries for the EPM Demo Applications as a result of the successful assignment to the SAP_BC_EPM_DEMO role.
13.9	As an administrator in the SAP system, start transaction PFCG. In the Role field, enter SAP_BC_EPM_DEMO. Click Display.
13.10	Swith to the User tab. You can see Linda's SAP user account LLARSON assinged to the role.

Done! Once again, thank you for following this tutorial and the blog series, and looking forward to your comments & feedback.

Push UUID from IAS to S4HANA - Tasks list on BTP task Center is empty for S4HANA

2026-01-01T05:41:20.344000+01:00

Introduction:

After completing all prerequisites and following the SAP documentation to configure the Task Center for an SAP S/4HANA system, it is quite common to encounter a situation where no tasks are displayed in the Task Center—even though task creation appears to be working correctly in the backend.

This blog addresses one of the most frequently overlooked root causes behind this issue: the absence of a Global User ID (UUID) in the SAP S/4HANA system. Even when the Task Center is correctly configured on SAP BTP and tasks are visible in the pull cache, missing UUID mapping can prevent the Task Center from resolving the processor correctly, resulting in an empty Task Center UI.

In this blog, I will walk you through a critical but often missed step required to ensure tasks are displayed correctly in the Task Center. The focus is on establishing a one-way synchronization from SAP Identity Authentication Service (IAS) to SAP S/4HANA to push the UUIDs for existing users, without performing a full user provisioning or re-synchronization.

Solution:

Even after configuring the Task Center on HANA on-premise and completing all required steps on BTP, the Task Center may appear empty, as shown in the screenshot below.

When you check the Task Center pull cache, you can see that the task exists; however, it is still not displayed in the Task Center app. As shown in the screenshot below, the task appears with the processor name set to the SAP user ID. This situation occurs when a GUID (UUID) is not available in the SAP HANA system. In such cases, the system falls back to using the SAP user ID instead of the UUID. As a result, the Task Center is unable to correctly resolve the processor, and the task is not displayed in the Task Center app.

To resolve this issue, we need to ensure that a UUID is available in the SAP system. The steps to achieve this are explained below. Before updating the UUID in the SAP HANA system, the user profile in the SU01 screen appears as shown in the screenshot below.
SU01-->Goto-->External User ID(UID)

Please note that in this scenario, we are not synchronizing SAP users to IAS and then syncing the UUID back to the HANA system. Since the UUIDs and users already exist in IAS as a result of the SuccessFactors integration, we will establish a one-way synchronization from IAS to SAP S/4HANA solely to push the UUID into the system

To push the UUID (Global User ID) to SAP system please follow below steps.

Prerequisite:
1. Login to your Cloud Connector: Make sure your Cloud connectors connection from BTP to HANA has access to below BAPI/FM

PRGN_ROLE_GETLIST
BAPI_USER_GETLIST
BAPI_USER_GET_DETAIL
BAPI_USER_CREATE1
BAPI_USER_ACTGROUPS_ASSIGN
IDENTITY_MODIFY
BAPI_USER_DELETE
PRGN_ACTIVITY_GROUPS_LOAD_RFC

2. Create a technical user in SAP HANA, or reuse an existing technical user that is used to pull tasks for the Task Center. Ensure that this user is assigned the required role listed below. This technical user will be used to create the RFC destination in the BTP subaccount, which will later be used to create the target system in IAS

SAP_BC_JSF_COMMUNICATION

3. Create a RFC destination on the BTP account where your IAS is hosted by referring to below SAP guide.
https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/create-rfc-destinations

Note: If you prefer to create the RFC destination in a different subaccount - perhaps within the same sub account as SAP Work Zone or the Task Center- ensure that you create an Identity Access Management (IAM) service instance in that subaccount. This is required so that the RFC destination you create is visible in the IAS administration console.

After completing the prerequisites, log in to IAS and create the source and destination systems to perform the push.

Creating Source system: Because the users are already available in IAS, select Local Identity Directory as the source system.
Creating the Source system is straightforward.

{
    "user": {
        "mappings": [
            {
                "sourcePath": "$.id",
                "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:User']['userId']",
                "targetVariable": "entityIdSourceSystem"
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userUuid']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userUuid']"
            },
            {
                "sourcePath": "$.schemas",
                "targetPath": "$.schemas",
                "preserveArrayWithSingleElement": true
            },
            {
                "sourcePath": "$.userName",
                "targetPath": "$.userName",
                "optional": true,
                "correlationAttribute": true
            },
            {
                "sourcePath": "$.displayName",
                "targetPath": "$.displayName",
                "optional": true
            },
            {
                "sourcePath": "$.groups",
                "targetPath": "$.groups",
                "optional": true,
                "preserveArrayWithSingleElement": true
            },
            {
                "sourcePath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:User']",
                "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:User']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystem']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystem']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystemId']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['sourceSystemId']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userId']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userId']",
                "optional": true
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']",
                "targetPath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']",
                "optional": true
            }
        ]
    },
    "group": {
        "ignore": true,
        "mappings": [
            {
                "sourcePath": "$.id",
                "targetVariable": "entityIdSourceSystem",
                "correlationAttribute": true
            },
            {
                "sourcePath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:Group']['name']",
                "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:Group']['name']"
            },
            {
                "sourcePath": "$.displayName",
                "targetPath": "$.displayName"
            },
            {
                "sourcePath": "$.members",
                "targetPath": "$.members",
                "optional": true,
                "preserveArrayWithSingleElement": true
            }
        ]
    }
}

Create Target system: Here our target is SAP HANA. below refer below screenshots and code snippet to create the same. here the target system type is SAP Application Server ABAP. and please select the destination which you created in prerequisite step 3.
Make sure you skip operations for delete and create as we trying to do update only and you can also update the alias(email), groups roles to S4HANA along with UUID but here i am only focusing on UUID.

{
    "user": {
        "skipOperations": [
            "create",
            "delete"
        ],
        "mappings": [
            {
                "sourceVariable": "entityIdTargetSystem",
                "targetPath": "$.USERNAME"
            },
            {
                "sourcePath": "$.userName",
                "targetPath": "$.USERNAME"
            },
            {
                "sourcePath": "$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['userUuid']",
                "targetPath": "$.SAPUSER_UUID.SAP_UID"
            },
            {
                "constant": "updateEntity",
                "targetVariable": "operationTypeVariable"
            },
            {
                "constant": "createEntity",
                "targetVariable": "operationTypeVariable",
                "scope": "createEntity"
            },
            {
                "condition": "$.active == false && '${operationTypeVariable}' == 'createEntity'",
                "constant": "X",
                "targetPath": "$.LOCK_LOCALLY"
            },
            {
                "condition": "'${operationTypeVariable}' == 'updateEntity'",
                "constant": "U",
                "targetPath": "$.LOCK"
            },
            {
                "condition": "$.active == false && '${operationTypeVariable}' == 'updateEntity'",
                "constant": "L",
                "targetPath": "$.LOCK"
            }
        ]
    }
}

Once the source and target systems are created, open the source system and perform a test run for a single user to ensure that everything is working correctly. After successful validation, you can remove the user filter and perform a mass update for all users in the system.

Once the update is completed you will be able to see UUID in SU01 user profile as below.

Also, The Task Center pull cache will have UUID for the processor field instead of the SAP user name and Tasks will be shown in the Task center as below.

Conclusion:

An empty Task Center—despite correct backend task creation and successful pull cache entries—can be misleading and time-consuming to troubleshoot. As demonstrated in this blog, the root cause is often the absence of a UUID in the SAP S/4HANA user master, which prevents the Task Center from resolving the task processor correctly.

By ensuring that the Global User ID (UUID) is pushed from IAS to SAP S/4HANA through a one-way synchronization, this issue can be resolved effectively without impacting existing user provisioning or SuccessFactors integrations. Once the UUID is updated in the SU01 user profile, the Task Center pull cache correctly reflects the UUID, and tasks become visible in the Task Center application as expected.

I hope this blog helps you avoid common pitfalls during Task Center setup and saves valuable troubleshooting time. Feel free to share your feedback or experiences, and happy learning!

Thanks and Regards,
Navyashree

Enhancing security: Enabling Multi-Factor Authentication enforcement for S-users

2026-02-06T13:51:09.128000+01:00

Starting from January 15, 2026, super administrators can enforce Multi-Factor Authentication (MFA) for their S-users. This new feature has been developed based on direct customer feedback and in response to the evolving security landscape, resulting in stronger protection for your user accounts.

What is Multifactor Authentication?

Multi-factor authentication, commonly known as MFA, is a powerful security measure that helps safeguard your accounts by requiring more than just a password. Instead of relying solely on something you know (like a password, PIN, or signature), MFA asks for an extra layer of verification, which could be:

Something you have: A one-time code generated by an authenticator app on your smartphone
Something you are: Biometrics, a fingerprint or a facial scan

By combining these different authentication factors, MFA makes it significantly tougher for attackers to break into your account. This is in fact one of the most effective ways to prevent unauthorized access and stop most data breaches.

Strengthening security with enhanced MFA Options for S-Users

Protecting critical SAP assets is crucial for our customers. Therefore, our approach to multi-factor authentication is evolving to meet this challenge. Now, super administrators can take a proactive role by enforcing MFA for S-users, while individuals still have the freedom to secure their accounts independently. This dual approach – administrator-led enforcement alongside voluntary enablement – offers the flexibility and meets modern security demands.

In the past, enabling MFA was left up to each S-user’s discretion. However, relying solely on voluntary enrollment is no longer sufficient to safeguard sensitive business information. By empowering both administrators and users, we’re making it easier to prevent unauthorized access and strengthen your organization’s security.

NEW scenario: Selective MFA enforcement by customer’s own super administrators

Now, super administrators can take a proactive role by enforcing MFA for S-users of their own company, while individuals still have the freedom to secure their accounts independently. Of course, this should be in line and aligned with the companies' own security policy.

Through the User Management Tool (UMT) in SAP for Me, super administrators have the option to activate MFA for S-users. This new feature allows administrators to:

Enforce MFA: Search for, filter, and select specific S-users or all of them to make MFA mandatory for their logins.
Exclude technical users: Crucially, super administrators can exclude specific technical accounts (like those used for the BTP cloud connector) from the MFA requirement, ensuring that core business processes continue to run smoothly.

After MFA is enforced, the selected S-user(s) will receive an email notification with simple instructions on next steps and be guided through a one-time setup on their next login, ensuring a seamless and secure transition.

EXISTING scenario: Voluntary MFA enablement by the S-users themselves

The option for individual users to proactively secure their own accounts remains fully available.

Any S-user can visit their profile page via SAP's profile management at any time to enable MFA for themselves. This has been a great option for security-conscious users who want to protect their accounts even before an administrator-led rollout.

Please note: MFA enforced by the super administrator overrides any voluntary setting previously configured by the user.