SAP Community - SAP Cloud Identity Services

Is it possible to configure scoped roles from SAP Datasphere in SAP Cloud Identity Service?

2025-11-27T12:51:51.667000+01:00

Answer: No, feature is not available.

Cloud Identity Services - GitHub at Your Service To Help with Feedback

2025-11-27T15:05:49.380000+01:00

Good documentation grows faster and better when users and authors work together. That’s exactly the spirit behind the initiative we started some time ago by opening the SAP Cloud Identity Services documentation to community feedback via GitHub.

Your questions, issues, and edits have directly helped us improve the documentation and shape Cloud Identity Services for the community. Please continue to share your experiences — whether it’s a quick correction, a clarification, or a new example — every contribution helps.

Why this matters for Cloud Identity Services users and authors:

Faster fixes and clearer guidance: When you report unclear wording or missing information, we - the authors can respond and update docs more quickly.
Direct collaboration: Instead of waiting for a support ticket or guessing, you can open a conversation right where the documentation lives.
Learn and contribute: Submitting edits is a great way to share real-world tips or correct examples that help everyone.

Thank you! and keep the feedback coming.

But how to do that? See the links in More Information below.

More Information

Identity Authentication Opens Its Documentation for Your Feedback with GitHub

SAP Open Documentation Initiative

SAP Cloud Identity Services

New Security Optimization Service for SAP Cloud Identity Services

2025-12-02T04:38:12.742000+01:00

Security is no longer optional—it’s the backbone of digital trust and business continuity.

The SAP Security Optimization Service (SOS) is designed to analyze, verify, and improve the security of your SAP system by identifying potential security risks and providing recommendations to mitigate these risks within the assessed systems.

There are many different SAP systems that can be analyzed with an SOS and can be referred from the CQC SOS Infosheet

🌟New in CQC SOS: SAP Cloud Identity Services!

What is CQC SOS for SAP Cloud Identity Services?

SAP Cloud Identity Services are a group of services of SAP Business Technology Platform (SAP BTP), which enable you to integrate identity and access management between systems.
Besides the CQC SOS for SAP BTP, which provides a security assessment of those security-relevant configurations and authorization assignments which are in the responsibility of the customer and focuses on reviewing the platform aspects, a new CQC SOS in the BTP realm is now available: CQC SOS for SAP Cloud Identity Services.

The CQC SOS for SAP Cloud Identity Services provides a security assessment structured in the following sections:

General Security Status for SAP Cloud Identity Services - e.g. security aspects related to administrator user/system management like critical authorizations and MFA enforcement, the security alert and notification configuration etc.
Security Checks for Identity Authentication - e.g. application specific checks like assigned password policy, MFA, Remember Me functionality etc.
Security Checks for Identity Provisioning - e.g. source and target system settings like logging and tracing for personal and sensitive data, SSL Server Certificate Verification etc.

📩How to request a CQC service?

Create an incident under component SV-BO-REQ (SAP Note 1296527) or

Contact the SAP Enterprise Support Advisory team via our Customer Interaction Center (C I C )

☁️As an SAP Enterprise Support or cloud customer:

Make use of the security and the enablement offerings provided by the SAP Enterprise Support Academy.

For more information on the topics discussed in this blog visit SAP Help Portal | SAP Online Help , Identity Authentication , Identity Provisioning

🔗Stay connected

Want to stay up to date on our services? Join our SAP Cloud ALM & Cross-Solution Topics Value Map and SAP Cloud Identity Services communities!

User Provisioning with Microsoft Entra ID (AD) in Cloud Identity Service

2025-12-10T07:50:10.594000+01:00

(A Complete Step-by-Step Guide)**

Hi Folks,

After extensive analysis and hands-on troubleshooting with user provisioning in SAP Cloud Identity Services, I decided to document the entire process. My goal is to help others quickly and smoothly integrate Microsoft Entra ID (formerly Azure Active Directory) with SAP Cloud Identity Services.

If you are planning to onboard corporate users into SAP’s Identity Authentication Service (IAS) using Identity Provisioning Service (IPS), this guide will save you hours of effort.

Requirement

Sync all corporate users from Microsoft Entra ID into SAP Cloud Identity Services (CIS).
These users already exist in Entra ID and need to be replicated to IAS.
Avoid manual user creation in IAS.
By configuring IPS, we can schedule daily jobs to automatically sync new or updated users.
Use the synced users in SAP BTP applications
(especially those using CIS for authentication) to assign roles, groups, and access for our SAP Build Work Zone.

Analysis

After diving deep into SAP Help documentation and performing several tests, I consolidated the exact approach that fulfills the requirement. The complete activity consists of five main steps.

Five-Step Integration Process

Step 1: Perform App Registration in Microsoft Entra ID

This activity is typically handled by the Azure team.
Refer to SAP Help documentation for detailed instructions:
Microsoft Entra ID Integration
https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/microsoft-entra-id

Once App Registration is complete, the Azure team will share the following information:

Application ID
Directory Tenant ID
Object ID
Client Secret Value
Client Secret ID
aad.domain.name

These parameters will be used in the Source System configuration of Identity Provisioning Service (IPS).

Step 2: Configure Microsoft Entra ID as a Source System in IPS

Follow the SAP Help documentation:
Microsoft Entra ID – Source System Configuration
https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/microsoft-entra-id

Below is the Screen Shot which shows the Source System:

Below is an example of mandatory source system properties:

Property Name Value

aad.domain.name	`<CompanyName>.onmicrosoft.com`
aad.group.attributes	id,displayName,mailNickname
aad.user.attributes	id,mail,userPrincipalName,displayName,mailNickname,givenName,surname,mobilePhone,businessPhones
Authentication	BasicAuthentication
ips.trace.failed.entity.content	false
oauth.resource.name	https://graph.microsoft.com
OAuth2TokenServiceURL	https://login.microsoftonline.com/<Company Name>.onmicrosoft.com/oauth2/token
Password	Client Secret Value
ProxyType	Internet
Type	HTTP
URL	https://graph.microsoft.com
User	Application ID

Below the screenshot for same:

Step 3: Configure Identity Authentication (IAS) as the Target System

SAP Help documentation for IAS as a target:
Identity Authentication – Target System Configuration
https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/target-identity-authentication

Important:
Select the correct Source System for this Target System.
Otherwise, IAS will attempt to read data from all existing source systems in IPS.

Below is the Screen shot of Target System for referece:

Mandatory IAS target system properties:

Property Name Value

Authentication	ClientCertificateAuthentication
ias.api.version	2
ias.user.unique.attribute	userName
ips.failed.request.retry.attempts	2
ips.failed.request.retry.attempts.interval	60
ips.trace.failed.entity.content	false
ProxyType	Internet
Type	HTTP
URL	https://`<CIS Domain Name>`.accounts.ondemand.com/

Step 4: Run the “Simulate Job”

Before performing the actual sync, run the Simulate Job from the Source System.

Below is the screen shot to run the Simulate Job:

This job allows you to check:

How many users will be read
What changes will be made
Any potential errors or mismatches

You can view results under Provisioning Logs in IPS.

Step 5: Run the “Read Job” (Actual User Sync)

This is the real provisioning job.

IPS reads users from Microsoft Entra ID
Then writes them into Identity Authentication Service (IAS)

Check Provisioning Logs for status, errors, or successful user creation.

Below is the screen shot for reference:

Optional: Schedule Recurring Provisioning Jobs

You can set up a scheduled job (daily, weekly, etc.) to automatically sync delta changes from Microsoft Entra ID into IAS.

This ensures user data stays consistently updated without manual intervention.

Summary

This guide provides all essential steps required to integrate Microsoft Entra ID with SAP Cloud Identity Services using Identity Provisioning Service (IPS). I hope it helps you streamline user onboarding and avoid manual user creation in IAS.

If you have any questions or face any issues, feel free to ask.

Regards,
Rohit Gera

SAP User Access Management in a Hybrid Landscape – Architecture and Key Concepts (Part 1)

2025-12-22T18:05:01.288000+01:00

This blog is Part 1 of a 3-part series on SAP User Access Management in a Hybrid Landscape.

• Part 1 – Architecture and Key Concepts (this post)
• Part 2 – Business Roles and Provisioning Models
• Part 3 – SAP IAG Two-Tenant Model: Challenges and Mitigation Strategies

Purpose

As organizations continue to adopt SAP cloud solutions, hybrid SAP landscapes—combining SAP S/4HANA in on-premise or private cloud environments with SAP SaaS applications and SAP BTP—have become increasingly common. While this model enables flexibility and innovation, it also introduces new challenges in managing user access consistently across systems.

This blog focuses on the architecture and key concepts behind managing user access in a hybrid SAP landscape using SAP GRC Access Control and SAP Identity and Access Governance (IAG) via the IAG Access Control Bridge. It outlines how these components work together with SAP Cloud Identity Services to provide centralized governance, controlled provisioning, and audit-ready access management across both on-premise and cloud applications.

Rather than providing step-by-step configuration instructions, this blog shares practical architectural guidance and implementation insights based on real-world project experience, complementing SAP’s official documentation and helping practitioners understand how to design an effective hybrid access management framework.

Scope and Landscape Overview

The scope of this blog is to outline an integrated user access management approach for a hybrid SAP landscape, covering both on-premise/private cloud ERP systems and SAP public cloud and SaaS applications.

In-Scope Systems

SAP S/4HANA (On-Premise or RISE Private Cloud)
SAP GRC Access Control 12
SAP Cloud Identity Access Governance – Integration Edition (IAG AC Bridge)
SAP Cloud Identity Services (IAS & IPS)
SAP Cloud Connector
SAP SaaS Applications
SAP BTP Applications

Target Architecture

High-Level Architecture Overview

The target architecture defines the end-to-end user access governance and provisioning model for a hybrid SAP landscape. This model integrates on-premise and private cloud SAP systems with SAP Public Cloud and SaaS applications, ensuring cohesive and centralized oversight. The solution leverages several key SAP technologies—SAP GRC Access Control, SAP Identity and Access Governance (IAG – Integration Edition), SAP Cloud Identity Services, and SAP Cloud Connector—to deliver consistent approval workflows, centralized governance, and automated provisioning across the entire SAP environment.

The following diagram illustrates the reference architecture for SAP user access management in a hybrid landscape, highlighting the interaction between SAP GRC Access Control, SAP IAG AC Bridge, SAP Cloud Identity Services, and SAP SaaS applications.

SAP GRC Access Control: Central Governance for Hybrid SAP Landscapes

Overview

SAP GRC Access Control operates as the primary governance and control layer for user access management across the hybrid SAP landscape. It provides a unified framework supporting both on-premise/private cloud and public cloud SAP applications, enabling organizations to maintain comprehensive oversight and streamlined processes for provisioning and managing user access.

Key Functional Capabilities

Access Request Management (ARM): Provides a centralized platform for intake and processing of access requests. Structured approval workflows ensure that every request is systematically reviewed and authorized according to organizational policies.
Access Risk Analysis: Performs real-time Segregation of Duties (SoD) analysis for on-premise systems and supported cloud environments, enabling proactive identification and mitigation of user access risks.
Business Role Management: Facilitates the design, maintenance, and lifecycle management of business roles, supporting the evolving access requirements of the organization.

Integration with On-Premise and Private Cloud SAP Systems

SAP GRC Access Control is directly integrated with core on-premise and private cloud SAP systems, such as SAP S/4HANA, SAP MDG, and SAP BW/4HANA. This integration is achieved through RFC-based communication, enabling essential functions including user provisioning and management, risk analysis and reporting, and business role management. All provisioning and governance activities for these systems are managed from SAP GRC Access Control, ensuring thorough audit traceability and alignment with internal control requirements.

Cloud Integration via SAP Cloud Connector and SAP IAG

The SAP Cloud Connector establishes a secure communication channel between the SAP cloud environment and the on-premise SAP landscape. Within the architecture, the SAP IAG subaccount on the Cloud Connector serves as an integration bridge, connecting SAP GRC Access Control with SAP Cloud Identity and Access Governance (IAG). This configuration enables cloud-to-on-premise RFC communication with GRC Access Control, supports SoD authorization checks, and allows approved access requests in GRC to be extended to SAP SaaS applications. This approach ensures organizations can apply their established GRC processes consistently across both on-premise and cloud environments.

SAP Cloud Identity and Access Governance (IAG) Integration for SAP SaaS Applications

Integration with SAP SaaS applications is facilitated through SAP Cloud Identity and Access Governance (IAG), which operates on the SAP Business Technology Platform (BTP). For clarity and security, IAG is deployed in a dedicated BTP subaccount, using the integration edition known as the IAG AC Bridge. Within this subaccount, a destination is configured to connect SAP GRC Access Control to the SAP Cloud environment via the Cloud Connector, ensuring secure and efficient access management. The IAG application is accessed through a dedicated URL, allowing administrators to manage configurations as required.

During the initial setup of IAG, administrators create an application entry for each SAP SaaS application that will be managed. This ensures that every application is properly integrated and governed within the overall access management framework. IAG utilizes SAP Cloud Identity Services for user provisioning, leveraging the Identity Provisioning Service to automate and monitor user access. For SaaS applications supporting direct provisioning through SCIM, a proxy system is configured for each application in Identity Provisioning, enabling secure and seamless user provisioning across the SAP SaaS ecosystem.

Summary and Next Steps

This first part of the series establishes the architectural foundation for SAP user access management in a hybrid landscape. By combining SAP GRC Access Control with SAP IAG AC Bridge and SAP Cloud Identity Services, organizations can extend centralized governance into SAP cloud applications while maintaining strong security and compliance controls.

In Part 2, we will focus on GRC Business Roles and provisioning models, including direct and federated access patterns across SAP S/4HANA and SAP SaaS applications.

SAP User Access Management in a Hybrid Landscape – Business Roles and Provisioning Models (Part 2)

2025-12-22T18:06:45.115000+01:00

Introduction

In Part 1 of this series, we explored the reference architecture for managing user access in a hybrid SAP landscape using SAP GRC Access Control, SAP Identity and Access Governance (IAG) via the IAG AC Bridge, and SAP Cloud Identity Services.

With the architectural foundation in place, this second part shifts focus to how access is actually designed and provisioned across on-premise and SAP cloud applications. In particular, it highlights the role of GRC Business Roles and explains the different provisioning models used for SAP S/4HANA and SAP SaaS applications.

Understanding these concepts is essential for building scalable, auditable, and maintainable access management processes in hybrid SAP environments.

Access Control: Business Role Management

Overview of GRC Business Roles

In SAP GRC, a Business Role comprises a set of access rights, permissions, and authorizations that can be assigned to multiple users who perform similar functions. Unlike traditional technical roles, Business Roles are designed to be system-independent, allowing organizations to streamline access management across various SAP applications. In a typical SAP Greenfield implementation, these Business Roles are crafted to reflect users' job functions or positions, ensuring both consistency and security for access to on-premise and cloud-based SAP solutions such as SAP S/4HANA, SAP Ariba, and SAP Sales Cloud.

Significance of GRC Business Roles in a Hybrid Landscape

The adoption of GRC Business Roles is especially crucial in a hybrid SAP landscape that encompasses both on-premise and cloud applications. By centralizing access provisioning and abstracting user permissions from the underlying technical roles, GRC Business Roles provide a unified structure for user access management. This approach ensures that users have consistent and appropriate access regardless of whether their work takes place in S/4HANA, Ariba, Sales Cloud, or a combination of these platforms. As organizations transition toward hybrid and cloud-centric architectures, GRC Business Roles facilitate secure, scalable, and efficient user access management—reducing complexity for administrators and minimizing risk by aligning permissions with business needs. This unified approach directly supports the document’s objectives of robust SAP User Access Management and governance across disparate systems.

Structure of GRC Business Roles

A GRC Business Role aggregates one or more technical roles from different systems into a single logical unit, simplifying the assignment process and ensuring users have access to the necessary tools and applications for their roles. Each Business Role consists of Technical Roles specific to individual applications or systems. These Technical Roles grant permissions for distinct modules or applications (e.g., "Accounts Payable Manager" in S/4HANA or "Requestor" in Ariba). GRC Business Roles are mapped to Technical Roles spanning multiple systems, such as:

SAP S/4HANA: Business process roles (e.g., Accounts Payable Manager, Maintenance Technician).
SAP Ariba: Groups or functional roles (e.g., Procurement Manager, Requestor).
SAP Sales Cloud: Sales-related roles (e.g., Sales Manager, Operations

Key Benefits of GRC Business Roles in Project Implementation

Unified access provisioning across SAP S/4HANA and SAP SaaS applications, reducing complexity.
Consistent access mapping aligned with Segregation of Duties (SoD) requirements and regulatory compliance.
Centralized role definition and assignment in GRC simplifies access management for administrators.
Automatic updates to technical roles when business roles change, ensuring accuracy.
Comprehensive access provisioning for users' job functions across multiple systems via a single Business Role.

Business Role Design Approach

The design of GRC Business Roles follows a structured process to ensure alignment with organizational job roles and access requirements:

Technical Role Design

The Security Team develops Technical Roles for each application, guided by detailed access requirements from:
- Process Design Documents: Identify transactions, applications, and authorizations required for each business process.
- User Stories: Outline access needs based on end-user roles and responsibilities.
- Workshops and Discussions: Collaborate with process teams to specify operational transactions and applications for each role.

Alignment with Organizational Job Roles

GRC Business Roles are structured according to users’ jobs and responsibilities as defined by the Organizational Change Management (OCM) Team.
User job roles are defined based on L3 Processes, representing detailed activities within each business process.
L3 Processes linked to each job role are reviewed to determine the necessary technical roles and access rights.
The Security Team creates GRC Business Roles based on these definitions, consolidating required technical roles across applications to ensure consistent and accurate access provisioning.

Detailed Provisioning Flows by Application Type

This section will provide an overview of the provisioning workflows for various applications within a hybrid environment.

SAP S/4HANA (On-Premise / Private Cloud)

Provisioning for SAP S/4HANA, whether deployed on-premise or in a private cloud environment, is facilitated through SAP GRC Access Control. The process is initiated when a user submits an access request using the GRC Access Request Management (ARM) module. Once the access request is submitted, it progresses through an approval workflow. This workflow typically involves the user's manager, the role owner, or the security team, depending on the organization's structure and policies.

During the approval process, a Segregation of Duties (SoD) risk analysis is conducted within GRC. This analysis ensures compliance with internal control requirements and helps minimize potential risks associated with conflicting access privileges. Upon successful approval, SAP GRC automatically assigns the designated roles directly to the S/4HANA system. The user's master record is subsequently updated through standard SAP connectors, enabling seamless integration and ensuring the accuracy of user data.

All audit logs generated during these provisioning activities are maintained within GRC. This comprehensive logging supports compliance requirements and enhances traceability. Notable characteristics of this provisioning flow include real-time SoD checks and immediate role assignment.

Direct Provisioning to SAP SaaS Applications (Ariba, SuccessFactors, SAC) via SCIM API

Provisioning for SAP SaaS applications that support the SCIM API, including Ariba, SuccessFactors, and SAP Analytics Cloud (SAC), is managed through SAP IAG leveraging the Identity Provisioning Service (IPS). The access request process is initiated using GRC Access Request, and the subsequent approval workflow follows a structure similar to the S/4HANA scenario. Once the access request is approved, GRC communicates the request to IAG using the Access Control Bridge (AC Bridge).

A scheduled provisioning job then runs at regular intervals to grant the requested access directly within the relevant SaaS applications. This automated process helps streamline user access management for cloud-based SAP solutions and ensures timely provisioning of roles.

Indirect Provisioning to SAP SaaS Applications (FSM, BTP)

For applications such as SAP Business Technology Platform (BTP) or Field Service Management (FSM), provisioning is managed by SAP IAG through the assignment of IAS Groups associated with these applications. Users submit access requests for specific IAS Groups, and these requests are routed through the required approval workflow. Upon approval, SAP IAG provisions the relevant IAS groups to the users.

For BTP, the IAS groups that are set up are linked to BTP role collections. When users next log in, they receive access to these specific collections. For applications such as FSM, which can interpret the assigned FSM IAS groups and map them to user policy groups within a company’s FSM environment, a scheduled read job on IPS will assign the appropriate user policy group and company automatically.

Please note: While Field Service Management (FSM) may not be explicitly included under an integration scenario for IAG, it is identified as both a source and target system within Identity Provisioning. Consequently, it is appropriate to utilize a combination of provisioning processes in order to provision end user access to FSM in such circumstances.

Summary and What’s Next

In this part of the series, we explored how GRC Business Roles and provisioning models enable scalable and controlled user access across hybrid SAP landscapes. By abstracting technical roles into business-aligned constructs and leveraging both direct and federated provisioning models, organizations can maintain strong governance while supporting diverse SAP applications.

In Part 3, we will focus on the SAP IAG two-tenant model, examining why it presents challenges in real-world implementations and how project teams can mitigate associated risks.

SAP User Access Management in a Hybrid Landscape – Challenges and Mitigation Strategies (Part 3)

2025-12-22T18:08:07.815000+01:00

Introduction

In the first two parts of this series, we covered the architecture and execution model for managing user access in hybrid SAP landscapes using SAP GRC Access Control and SAP Identity and Access Governance (IAG) via the IAG Access Control Bridge.

In this final part, we focus on a topic that frequently surfaces during implementations but is often underestimated during planning—the SAP IAG tenant model. Specifically, we examine why the standard two-tenant model introduces challenges when integrated with a typical three-tier SAP GRC Access Control landscape, and how project teams can mitigate these challenges in practice.

Challenges and Considerations with the SAP IAG Two-Tenant Model

Overview of SAP IAG Tenant Mapping

SAP Identity and Access Governance (IAG) enforces a strict tenant-to-system mapping model when integrated with SAP GRC Access Control through the IAG AC Bridge. According to SAP Note 3389374, only one SAP Access Control system can be mapped to one IAG tenant. SAP advises against connecting multiple Access Control systems to the same IAG tenant to avoid potential data inconsistencies. The guidance further highlights that after an Access Control system has been connected and data synchronized with an IAG tenant, no other Access Control system should be connected to that tenant, even if the previous system has been disconnected. SAP explicitly states that they may not take responsibility for any resulting data inconsistencies. Therefore, the number of IAG tenants should align with the number of Access Control systems.

Typical Landscape Mismatch

In practice, most SAP customers operate a three-tier SAP GRC Access Control landscape, consisting of Development (DEV), Quality/Test (QAS), and Production (PRD) systems. However, SAP typically provisions only two IAG tenants per customer: one for Test and one for Production. This two-tenant limit also applies to several SAP SaaS solutions, such as Ariba, Fieldglass, and FSM, as well as SAP Cloud Identity Services. This creates a structural mismatch between the number of SAP Access Control systems and the available IAG tenants.

Figure: Typical mismatch between SAP GRC Access Control landscapes and IAG tenant availability

Challenges During Project Implementation

Note: While this discussion refers to the SAP GRC Access Control system, it is important to note that in most Greenfield implementations today, GRC Access Control is deployed as an embedded component within the SAP S/4HANA system. The overall three-to-six-month implementation timeline in the development system typically reflects the broader S/4HANA program, encompassing multiple business processes, and not GRC in isolation.

During project implementations, especially in Greenfield scenarios, the SAP GRC Access Control Development system is usually implemented first and is available early in the project lifecycle. At this stage, configuration and development activities take place in the DEV system, and the Realize and Build phases can extend over three to six months. Early integration of the IAG AC Bridge is often required to support access request testing, role design validation, and initial cloud provisioning scenarios. However, the Quality (QAS) Access Control system—which ideally should connect to the IAG test tenant—may not be available until just before formal testing begins.

This situation presents a dilemma. While SAP recommends a one-to-one mapping between Access Control systems and IAG tenants, most customers do not have more than the standard two IAG tenants. Procuring an additional IAG tenant is often cost-prohibitive, not planned in the initial contract, and operationally challenging.

Practical Implications for IAG AC Bridge Setup

With only two IAG tenants, setting up the IAG AC Bridge can be particularly complex when the GRC QAS system is not yet available, but integration testing needs to start during the development phase. Early validation of cloud provisioning scenarios is also impacted. As a result, project teams are often forced to make architectural and sequencing decisions that are not directly addressed in SAP's official documentation.

Recommended Mitigation Approach

Early Availability of GRC QAS: If possible, teams should bring up the GRC Quality system earlier than originally planned, aligning its availability with the IAG Test tenant timeline. This enables completion of IAG AC Bridge integration in a supported manner, provides sufficient time for end-to-end testing without rework, and reduces last-minute risks during formal testing.
Adequate Time for Production Deployment: When deploying the integration in Production, ample lead time should be allowed. It should not be assumed that configurations can be transported end-to-end. Approximately 60% of the IAG AC Bridge integration steps performed in Test must be repeated manually in Production, as these steps are tenant-specific, involve cloud-side configurations, and cannot be transported using SAP CTS.

Disconnecting and Reconnecting Access Control Systems

Although SAP does not recommend disconnecting an Access Control system from an IAG tenant to connect a new one, in some controlled project scenarios, teams have executed this approach without observing significant functional or data consistency issues, provided strict procedural discipline was followed. However, this approach should be clearly documented, approved by the customer, and understood as a pragmatic workaround rather than an SAP-endorsed best practice.

Additional Functional Considerations in IAG AC Bridge Scenarios

User Access Review

User Access Reviews can continue to be performed within Access Control, following the established process. Upon completion of the review, a provisioning or deprovisioning request is automatically generated in IAG for the corresponding SaaS application related to the review request. For S/4HANA roles, these are removed automatically once the review request is submitted.

SOD Review Process

The SOD (Segregation of Duties) Review Process is not supported within the GRC IAG AC Bridge environment.

Workflow Limitations in GRC

Function, Risk, and Mitigating Control workflows are no longer available in GRC, as ruleset maintenance must now be conducted within IAG.

Mitigating Controls Monitoring

Mitigating controls monitoring can be performed within IAG. Additionally, test results for these controls can be uploaded directly to IAG.

User and Role Simulation

User and role level simulations for S/4HANA risks are not supported in IAG but may still be carried out in GRC AC. If simulations are performed, customers should validate this approach with SAP and ensure alignment with supported usage scenarios.

Conclusion

Across this three-part series, we explored how SAP user access management can be effectively designed and implemented in modern hybrid SAP landscapes.

Part 1 established the architectural foundation, explaining how SAP GRC Access Control, SAP Identity and Access Governance (IAG), and SAP Cloud Identity Services work together to extend centralized governance into SAP cloud applications.
Part 2 focused on execution, highlighting the importance of GRC Business Roles and outlining direct and federated provisioning models across SAP S/4HANA and SAP SaaS applications.
Part 3 examined the practical challenges introduced by the SAP IAG tenant model and shared mitigation strategies based on real-world implementation experience.

Together, these perspectives demonstrate that while SAP provides a robust framework for hybrid access management, successful implementations require early planning, architectural clarity, and pragmatic decision-making—particularly when navigating tenant constraints and project timelines.

By combining strong role design, well-defined provisioning models, and a clear understanding of platform limitations, organizations can achieve secure, scalable, and auditable user access management across both on-premise and cloud SAP environments.

SAP Cloud Logging Service ダッシュボードを IAS の SAML 認証で利用する方法

2025-12-30T10:25:31.386000+01:00

English version

はじめに

SAP Cloud Logging Service（以下、CLS）は、アプリケーションログやメトリクスを一元的に管理できる、OpenSearch ベースのオブザーバビリティサービスです。

CLS が提供する Dashboards では上記のようなアプリケーションデータを閲覧できるため、アクセス制御や認証方式には適切なセキュリティ対策が求められます。

CLS ダッシュボードは Service Key を用いたアクセスも可能ですが、本番環境ではユーザー管理やセキュリティの観点から、IAS を利用した SAML 認証が推奨されています。

そこで、本記事では、CLS ダッシュボードで SAML 認証を利用するために必要な設定手順を解説します。

前提条件

以下の条件を満たしていることを前提とします。

IAS テナントが有効化されていること
SAP BTP サブアカウントで CLS が利用可能であること
IAS とBTPサブアカウントの管理者権限を持っていること

手順1 : IAS で SAML 2.0 アプリケーションを作成

IAS 管理画面で ‘Applications & Resources’ > ’Applications’ を開き、アプリケーションを作成します。

Display Name : <任意>
Protocol Type : SAML 2.0

手順2 : CLSインスタンスの作成と SAML 設定

既存の CLS インスタンスがある場合は、インスタンス作成時と同様にパラメータを更新することで対応可能です。

本記事では、新規インスタンス作成時の設定手順を説明します。

2-1. CLS インスタンスの作成

BTPサブアカウント上でCLSインスタンスを作成します。

Service：Cloud Logging
Plan、Runtime Environment：<用途に応じて選択>
Instance Name：<任意>

入力後、「Next」をクリックし、パラメータ設定画面へ進みます。

2-2. SAML パラメータの設定

デフォルトのパラメータが表示されるため、saml セクションを編集します。

デフォルトのパラメータ設定

編集後のパラメータ設定

{
  "saml": {
    "enabled": true,
    "admin_group": "<IAS_ADMIN_GROUP_NAME>",
    "initiated": true,
    "roles_key": "groups",
    "idp": {
      "metadata_url": "<IAS_TENANT_URL>/saml2/metadata",
      "entity_id": "<IAS_IDP_ENTITY_ID>"
    },
    "sp": {
      "entity_id": "<CLS_SP_ENTITY_ID>"
    }
  }
}

samlセクションのテンプレート

各パラメータの説明

admin_group

指定した IAS グループに属するユーザーに管理者権限（all_access）が付与されます。本記事では 'cls-admin' と設定します。

idp.metadata_url

CLSが IAS から SAML メタデータを取得するための URL です。IAS テナントのエンドポイントに /saml2/metadata を付与して指定します。例えば、IAS テナントが 'https://<YOUR-TENANT-NAME>.accounts400.ondemand.com'の場合、'https://<YOUR-TENANT-NAME>.accounts400.ondemand.com/saml2/metadata'を設定します。

idp.entity_id

上記 metadata_url をブラウザで開き、XML の先頭に記載されている entityID の値を設定します。

sp.entity_id

Service Provider としての CLS を識別する ID で、今回は 'CLS-Demo' を使用します。IAS 側の SAML 設定において、同じ値を登録する必要があります。

手順3 : IAS 側の SAML 設定

IAS のアプリケーション設定画面で Configure Manually を選択し、SAML 設定を行います。

Entity ID：<CLSインスタンスの sp.entity_id と同じ値>

SAML 連携において Service Provider（CLS）を一意に識別するためのID です。CLS 側の SAML 設定で指定した SP Entity ID と同じ値を設定しなければいけませんので、今回は 'CLS-Demo' となります。

エンドポイント設定

SSO Endpoint : <Dashboards URL>/_opendistro/_security/saml/acs
Single Logout Endpoint : <Dashboards URL>

動作確認 (認証)

CLS の Dashboards URL にアクセスし、認証が通ることを確認します。

この時点では、ダッシュボードやインデックス一覧を開くとブランクなページが表示されたり、権限不足のエラーが表示されたりします。

Developer Tools でも HTTP 403 (Forbidden) が返却されていることが確認できます。

また、ユーザーアイコンから”View roles and identities”をクリックして付与されているロールを確認すると、付与されているロールは own_index のみであることが確認できます。

これは SAML 認証は成功しているものの、ロール割り当て（認可）が未設定であるために発生しています。

手順4 : IAS アプリケーションの Attributes 設定

CLS 側で IAS のグループ情報をロール割り当てに利用するため、SAML アサーションにグループ情報を含める必要があります。

IAS アプリケーションの Attributes を開き、以下を設定します。

Name : groups
Source : Identity Directory
Values : All Groups

手順5：グループ作成とユーザー追加

手順2で設定した admin_group と同じ名前のグループを IAS の User Groups に作成します。今回は、'cls-admin'となります。

Name：<CLSインスタンスの admin_group と同じ値>
Display Name : <任意>

対象のユーザーを追加します。

動作確認 (認可)

再びダッシュボードページにアクセスすると、ダッシュボード一覧が表示されていることが確認できます。

また、ユーザーに cls-admin 経由で all_access ロールが付与されていることも確認できます。

BTPを使ったアプリケーション開発・運用のお役に立てれば幸いです！

参考

How to Access SAP Cloud Logging Service Dashboards Using IAS SAML Authentication

2025-12-30T11:14:12.065000+01:00

Japanese version

Introduction

SAP Cloud Logging Service (CLS) is an OpenSearch-based observability service that allows you to centrally manage application logs and metrics.

Because CLS Dashboards provide access to application data such as logs and metrics, proper security measures such as authentication methods and access control are essential.

Although CLS Dashboards can be accessed using a Service Key, SAP recommends using SAML authentication with IAS in production environments to ensure proper user management and stronger security.

In this article, we walk through the configuration steps required to enable SAML authentication for CLS Dashboards using IAS.

Prerequisites

This guide assumes the following conditions are met:

An IAS tenant is active
SAP Cloud Logging Service is available in your SAP BTP subaccount
You have administrator privileges for both IAS and the BTP subaccount

Step 1: Create a SAML 2.0 Application in IAS

In the IAS administration application, navigate to Applications & Resources → Applications, and create a new application.

Display Name: Any name
Protocol Type: SAML 2.0

Step 2: Create a CLS Instance and Configure SAML

If you already have an existing CLS instance, you can update its parameters in the same way as during instance creation.

In this article, we describe the steps using a new CLS instance.

2-1. Create a CLS Instance

Create a CLS instance in your BTP subaccount.

Service: Cloud Logging
Plan / Runtime Environment: Choose according to your use case
Instance Name: Any name

After entering the values, click Next to proceed to the parameter configuration screen.

2-2. Configure SAML Parameters

The default parameters will be displayed. Edit the saml section as shown below.

Default parameters

Updated parameters

{
  "saml": {
    "enabled": true,
    "admin_group": "<IAS_ADMIN_GROUP_NAME>",
    "initiated": true,
    "roles_key": "groups",
    "idp": {
      "metadata_url": "<IAS_TENANT_URL>/saml2/metadata",
      "entity_id": "<IAS_IDP_ENTITY_ID>"
    },
    "sp": {
      "entity_id": "<CLS_SP_ENTITY_ID>"
    }
  }
}

saml section template

Parameter Explanation

admin_group
Users who belong to the specified IAS group are granted administrator privileges (all_access).
In this example, we use cls-admin.

idp.metadata_url
The URL from which CLS retrieves SAML metadata from IAS.
Append /saml2/metadata to your IAS tenant URL.
For example, if your IAS tenant URL is:
https://<YOUR-TENANT-NAME>.accounts400.ondemand.com

then set:
https://<YOUR-TENANT-NAME>.accounts400.ondemand.com/saml2/metadata

idp.entity_id
Open the metadata_url in a browser and set the value of 'entityID' found at the beginning of the XML.

sp.entity_id
The identifier for CLS as a Service Provider. In this example, we use 'CLS-Demo'. The same value must be configured on the IAS side.

Step 3: Configure SAML Settings in IAS

In the IAS application settings, select Configure Manually and configure the SAML settings.

Entity ID: Same value as 'sp.entity_id' of the CLS instance

This ID uniquely identifies CLS as the Service Provider in the SAML integration.
Since we used 'CLS-Demo'in the CLS configuration, the same value must be set here.

Endpoint Configuration

SSO Endpoint: <Dashboards URL>/_opendistro/_security/saml/acs
Single Logout Endpoint: <Dashboards URL>

Verification (Authentication)

Access the CLS Dashboards URL and confirm that authentication succeeds.

At this point, when opening dashboards or index lists, you may see a blank page or permission-related errors.

In Developer Tools, you can also confirm that HTTP 403 (Forbidden) responses are returned.

If you click View roles and identities from the user icon, you will see that only the 'own_index' role is assigned.

This indicates that SAML authentication is working correctly, but authorization (role assignment) has not yet been configured.

Step 4: Configure Attributes in the IAS Application

To use IAS group information for role assignment in CLS, group data must be included in the SAML assertion.

Open Attributes in the IAS application and configure the following:

Name: groups
Source: Identity Directory
Values: All Groups

Step 5: Create a Group and Add Users

Create a user group in IAS with the same name as the 'admin_group' configured in Step 2.
In this example, the group name is 'cls-admin'.

Name: Same as 'admin_group'
Display Name: Any name

Add the target users to the group.

Verification (Authorization)

Access the dashboard page again and confirm that the list of dashboard is now visible.

You can also verify that the 'all_access' role has been assigned to the user via the 'cls_admin' group.

I hope this article helps you with application development and operations on SAP BTP!!

References

SAP S4HANA Fiori Launchpad authentication via IAS (SAP Cloud Identity services)

2026-01-05T16:58:36.858000+01:00

Hello,

This blog will help us configure our S4HANA Fiori through SAP Cloud Identity Services and still using our own corporate IDP.

This is one of prerequisite of enabling joule for S4HANA Fiori launchpad for private cloud edition.

Our organization is already having SAML authentication for our Fiori users with our corporate IDP but in order to use Joule within Fiori SAP Fiori should also use same authentication method as that of Joule.

Architectural flow

Steps to integrate Fiori with IAS

Get the SAML Metadata of Your Identity Authentication Tenant
Create an App for Your SAP S/4HANA Solution
Enable the ABAP Platform as an SAML Service Provider
Trust Identity Authentication as an Identity Provider
Trust the ABAP Platform Client as a Service Provider
Configure Corporate IDP in SAP IAS
Configuring the Conditional authentication for your app in IAS

Get the SAML Metadata of Your Identity Authentication Tenant

Under Applications & Resources, choose the Tenant Settings tile.

Choose the SAML 2.0 Configuration list item.

Choose Download Metadata File.

From the Signing Certificate section, download the certificate too.

Create an App for Your SAP S/4HANA Solution

Under Applications & Resources, choose the Applications tile.

Choose the Create button.

Enter the required information.

Set the Application Type to SAP on-premise Solution.

Click on create.

Enable the ABAP Platform as an SAML Service Provider

If your ABAP client has never been configured for SAML, you see the message Client "<Client_Id>" is not configured to support SAML 2.0.

To enable the configuration, choose Enable SAML 2.0 Support --> Create SAML 2.0 Local Provider.

Enter a name for the provider.

Choose Metadata.

Save the metadata to a file, such as abap_client_metadata.xml.

Trust Identity Authentication as an Identity Provider

In SAML2 tcode goto Trusted Provider and click on add

Select the metadata file you downloaded from your Identity Authentication tenant for upload and choose Next.

Then you need to choose the certificate which you have downloaded from tenant setting

once you finish the wizard. provider is added as shown below

click on identity federation and click add

you can save and activate this provider

Trust the ABAP Platform Client as a Service Provider

Under Applications & Resources, choose the Applications tile.

Select the application you created for your ABAP Platform client

Under the Trust tab, choose SAML 2.0 Configuration.

Upload the service provider metadata XML file which you downloaded from SAML2 tcode

Configure Corporate IDP in SAP IAS

prerequisite : you need metadata file from your corporate IDP

click on SAML configuration

Name ID format you can keep unspecified

Configuring the Conditional authentication for your app in IAS

select your application " SAP ABAP " in my case

then scroll down to conditional authentication

choose the corporate IDP which you create in above step and click on save

you have to trust your corporate IDP

you are all set

now when request comes from SAP Fiori it will be redirected to SAP IAS and SAP IAS will redirect that request to your corporate IDP. It will pass the authentication and same will be pass on to your SAP application by SAP IAS. It will just act like proxy.

In case if you are not using Corporate IDP for login then you need to create each SAP user in your SAP IAS so that they can login fiori with your SAP IAS login credentails.

Reference Article : https://help.sap.com/docs/cloud-identity/system-integration-guide/identity-authentication-configuration-for-sap-s-4hana?locale=en-US

New Expert-Guided Implementation: Joule Prerequisites and Activation

2026-01-16T00:06:43.973000+01:00

Establish the Foundation for Your AI Journey

SAP Joule is transforming how organizations interact with SAP applications by bringing intelligence directly into everyday workflows. For customers to activate Joule and unlock its AI-powered capabilities, they must first prepare their SAP Cloud Identity Services (CIS), SAP Business Technology Platform (BTP), and integration foundations to fully realize the value of Joule from day one.

To support customers with this essential preparation, we are pleased to introduce a new Expert-Guided Implementation (EGI):

Joule Prerequisites & Activation - a hands-on, expert-led program designed to help you configure all required technical components for a smooth Joule activation.

This new offering helps customers understand Joule’s architecture, explore deployment options, configure platform prerequisites, and establish the identity and access foundation required for a secure activation. By the end of the EGI, participants will be positioned to complete all the prerequisites required to activate Joule, ensuring a seamless start to their AI adoption journey.

Workshop Schedule

To accommodate global participants, this session will be offered on the following dates and time zones as follows:

2026 Dates	Time	Time Zone
January 19-20	10:00AM - 12:00PM	EMEA \| CET
January 26-27	11:00AM - 1:00PM	NA/LA \| EST
February 9-10	10:00AM-12:00PM	EMEA \| CET
February 16-17	11:00AM - 1:00PM	NA/LA \| EST
March 2-3	10:00AM-12:00PM	EMEA \| CET
March 9-10	11:00AM - 1:00PM	NA/LA \| EST

Why This EGI Matters

Before Joule can be activated, customers must ensure the right technical prerequisites are in place—across SAP BTP, Cloud Identity Services, Build Work Zone, and Line-of-Business systems. This EGI provides:

A clear, step-by-step path to completing these prerequisites

Expert-led guidance for setting up SAP Cloud Identity Services including Identity Authentication Service (IAS)/Identity Provisioning Service (IPS), and entitlements

Live configuration guidance in your SAP BTP environment and SAP Build Workzone (BWZ)

Hands-on support through real examples and troubleshooting

With AI rapidly becoming central to SAP’s product strategy, organizations need the right technical foundation to adopt Joule with confidence, security, and scalability.

What You’ll Learn: Program Overview

This 2-day EGI blends instruction, demonstrations, and guided hands-on exercises.

Day 1 – Foundation & Architecture

Understand Joule’s system architecture and deployment scenarios

Learn how SAP Cloud Identity Services (IAS/IPS), SAP BTP, SAP Build Work Zone, and LOB solutions work together

Navigate BTP global accounts, subaccounts, entitlements, and subscriptions

Validate system readiness and begin configuring your Joule environment

Experience a live demonstration of Joule integrated with SAP SuccessFactors

Day 2 – Identity, Provisioning & Work Zone Integration

Deep-dive into SAP Cloud Identity Services - Identity Authentication (IAS) and Identity Provisioning (IPS) for Joule

Integrate CIS with your corporate Identity Provider

Configure SAP Build Workzone (BWZ) as the unified interface for Joule

Establish trust relationships between systems

Expose LOB content to BWZ and validate provisioning flows

What You Will Achieve

This new EGI equips your organization with everything needed to prepare for Joule activation, ensuring compliance, security, and a streamlined technical foundation from day one.

If your organization is planning to adopt SAP Joule or preparing for AI-driven innovation within SAP applications, this EGI is the ideal starting point to fast-track your readiness and reduce implementation risk.

By the end of the EGI, you will have:

A configured SAP BTP environment with a designated Joule subaccount

Completed IAS/IPS setup for secure authentication and provisioning

Integrated BWZ as the experience layer for Joule

Verified all activation prerequisites using a comprehensive readiness checklist

Gained expert-backed confidence to run the Joule Booster and proceed with activation

How to Register

Register here to secure your spot* today to learn from SAP experts and gain the skills to bring Business AI to life across your enterprise.

* You may need to register your S-user for access to SAP Learning Hub to access the EGI registration page. It is a one-time registration, click here.

Unlocking Joule and SAP Business AI from Strategy to Activation: Expert-Guided Implementation

Creating and Accessing an IAS Tenant on SAP BTP (Part 2)

2026-01-20T06:19:07.567000+01:00

In Part 1 of this series, the role of SAP Cloud Identity Services – Identity Authentication (IAS) as a foundational component for enterprise-grade SAP Decentralized Identity Verification (DIV) implementations was introduced.

This article focuses on creating and accessing an IAS tenant on SAP BTP.
At this stage, no DIV-specific configuration is performed. Instead, the identity foundation required for later integration with DIV is prepared.

Positioning in the Overall Architecture

At a high level, IAS acts as a central authentication and authorization layer between corporate identity providers and DIV components.

This architectural positioning corresponds to the enterprise requirements introduced in Part 1, where IAS acts as the central identity layer between corporate identity providers and DIV (Figure 1).

Figure 1: High-level identity architecture integrating SAP Cloud Identity Services (IAS) with SAP Decentralized Identity Verification (DIV).

Prerequisites

Before starting the setup, the following prerequisites must be fulfilled:

An SAP BTP global account
A BTP subaccount (existing or newly created)
Administrative permissions to:
- Manage entitlements
- Create service instances
- Configure identity services

Step 1: Access the SAP BTP Global Account

Open the SAP BTP Cockpit: https://account.hana.ondemand.com/#/home/welcome
Log in using SAP credentials
Select the relevant global account

Note:
In enterprise environments, multiple global accounts may exist (for example, development, test, and production). The correct global account for the DIV implementation must be selected.

Step 2: Select or Create a Subaccount

Subaccounts provide logical isolation for different projects, environments, or organizational units.

In the left navigation panel, open Account Explorer
Either:
- Select an existing subaccount, or
- Create a new subaccount:
  1. Click Create → Subaccount
  2. Enter a display name (e.g. manufacturer-div-test)
  3. Select a region (e.g. AWS, Europe)
  4. Click Create

Step 3: Check and Add Cloud Identity Service Entitlements

IAS is provided as part of SAP Cloud Identity Services and must be entitled before it can be consumed within a subaccount.

In the subaccount, navigate to Entitlements
Search for Cloud Identity Services
If the service is already listed, continue with the next step
If the service is not listed:
1. Click Edit in the top right corner
2. Select Add Service Plans (top right)
3. Search for Cloud Identity Services
4. Select the service
5. Choose the default application plan
6. Click Add Service Plan
7. Click Save

Good to know:
Each SAP BTP global account includes one free production IAS tenant and one free test IAS tenant.

Step 4: Create an IAS Instance

The IAS instance represents the actual IAS tenant that will later serve as the identity provider for DIV.

In the subaccount navigation, go to Services → Instances and Subscriptions
Click Create
Configure the instance with the following values:
- Service: Cloud identity Service
- Plan: default
- Runtime environment: Cloud Foundry
- Instance name: for example, manufacturer-div-ias-test
Click Create

Provisioning of the IAS tenant typically completes within 1-2 minutes.

Step 5: Access the IAS Admin Console

After provisioning is complete, the IAS administration interface becomes available.

In Instances and Subscriptions, locate the newly created IAS instance
Click on the instance name to open the instance details
Open the Admin Console or Dashboard URL (URL format: https://<tenant-id>.accounts.ondemand.com/admin)
Log in using SAP credentials

The IAS Admin Console is the central place for:

Managing users and groups
Configuring authentication and identity federation
Controlling access to DIV wallets and provisioning tenants

Result

After completing the steps above:

An IAS tenant is successfully provisioned on SAP BTP
The IAS Admin Console is accessible
No integration with DIV has been configured yet

This completes the identity foundation required for the DIV setup.

➡️ Continue with Connecting IAS with SAP Decentralized Identity Verification (Part 3)

⬅️ Go back to Why IAS Is Essential for Enterprise DIV Implementations (Part 1)

Why IAS Is Essential for Enterprise DIV Implementations (Part 1)

2026-01-20T12:16:13.294000+01:00

This is Part 1 of a three-part series on setting up SAP Cloud Identity Services – Identity Authentication (IAS) with the BTP service Decentralized Identity Verification (DIV). It lays the foundation by explaining what IAS is and why it is a core building block for enterprise-grade DIV implementations.

Introduction

Consider a scenario where a global automotive manufacturer has decided to implement SAP’s Decentralized Identity Verification (DIV) solution to enable secure, privacy-preserving digital identity management across its supply chain. The company needs to issue verifiable credentials to suppliers, partners, and employees while maintaining full control over the authentication infrastructure.

However, there’s a critical requirement: the organization wants to use its own corporate identity system rather than creating and managing separate user accounts in SAP. Employees and suppliers should authenticate using their existing corporate credentials, such as those from the manufacturer’s domain or a gearbox supplier’s identity provider, not additional SAP-specific identities.

Additionally, granular access control is essential. The manufacturer needs to define which users can access specific digital wallets and which administrators have the authority to provision and manage these wallets across different business units and partner organizations. This is where SAP Cloud Identity Services – Identity Authentication (IAS) becomes indispensable.

What is IAS?

IAS is a cloud-based identity management solution that serves as a central authentication and single sign-on (SSO) hub for SAP and non-SAP applications.

Core Capabilities

Single Sign-On (SSO): Users authenticate once and gain access to multiple applications without repeated logins.
Identity Federation: IAS can integrate with existing corporate identity providers (like Microsoft Azure AD, Google Workspace, etc.) through standards like SAML 2.0 and OpenID Connect (OIDC). This avoids duplicate user accounts.
Fine-Grained Access Control: Users can be assigned access to specific applications or resources—critical for multi-tenant DIV wallet scenarios.
Centralized User Lifecycle Management: Manage users, groups, authentication policies, and access rights consistently across systems.

Why Use IAS with DIV?

While DIV can technically operate without IAS, enterprise deployments strongly benefit from it. IAS addresses three core challenges: identity reuse, access control, and security.

1. Reusing Existing Corporate Identities

Most organizations already operate mature identity systems. IAS allows DIV to integrate seamlessly by:

Federating with corporate and partner identity providers
Eliminating DIV-specific user accounts
Simplifying onboarding and offboarding: disabling a corporate account automatically revokes DIV access

This ensures users authenticate with familiar credentials while IT retains centralized control.

2. Granular Access Control in Multi-Tenant Environments

In realistic enterprise scenarios, different stakeholders require different levels of access. Consider the automotive manufacturer example: The finance department needs access to a dedicated wallet tenant for financial audit credentials. The supply chain team requires access to supplier verification credentials in a separate tenant while quality assurance must access quality certification credentials without visibility into financial or HR data. Furthermore, an external gearbox supplier should only access the specific wallet tenant designated for supplier interactions.

IAS enables this sophisticated access model through:

Group-based access control mapped to DIV wallet tenants
Role-based administrative permissions for provisioning and management
Tenant isolation, preventing unauthorized access across departments or partners

3. Centralized Security and Auditability

Without IAS, organizations would need to manage separate authentication mechanisms for DIV, adding complexity and risk. IAS provides:

Central enforcement of security policies (e.g. MFA, password rules, session timeouts)
Reduced credential sprawl and fewer attack surfaces
Improved visibility into authentication activity for security monitoring and audits

What this Series Will Build

To provide concrete context throughout this series, the following scenario is used: an automotive manufacturer implementing DIV with the following requirements:

Authentication:

Employees from the manufacturing company authenticate using their corporate domain credentials
Partner organizations (such as a gearbox supplier) authenticate using their own identity systems, federated through IAS
Authentication is mandatory before opening any DIV wallet or accessing the DIV provisioning interface

Authorization:

Define which employees can open which wallet tenants (e.g., finance employees cannot access HR credential wallets)
Define which administrators from the manufacturer can provision wallet tenants
Define which administrators from partner organizations (like gearbox supplier) can manage their own supplier wallets
Map corporate roles to predefined DIV user roles and permissions

Outcome:

The manufacturer maintains full control over user identities, access rights, and administrative boundaries while enabling seamless integration with partner organizations’ identity systems using IAS.

➡️ Continue with Creating and Accessing an IAS Tenant on SAP BTP (Part 2)

➡️➡️ Jump to Connecting IAS with SAP Decentralized Identity Verification (Part 3)

Connecting IAS with Decentralized Identity Verification (DIV) (Part 3)

2026-01-23T10:29:29.783000+01:00

In Part 1, the role of SAP Cloud Identity Services – Identity Authentication (IAS) as the central identity layer for Decentralized Identity Verification (DIV) was introduced.
In Part 2, an IAS tenant was created and made accessible on SAP BTP.

This article completes the setup by connecting the IAS tenant to DIV, explaining how authentication and authorization are enforced, and showing how administrators and end users are granted access to DIV provisioning and wallet tenants.

Authentication and Authorization Overview

Once IAS is connected to DIV, all access to DIV components is mediated by IAS. This applies to both:

DIV Provisioning UI (administrative access)
DIV Wallet Tenants (end-user access)

During authentication, IAS performs two checks:

Authentication by verifying the user’s identity via the federated corporate identity provider
Authorization by validating whether the authenticated user is allowed to access the requested DIV tenant or application

Only if both checks succeed access is granted.

This model ensures that authentication and authorization decisions are consistently enforced across the DIV components.

Step 1: Starting DIV Provisioning via SAP for Me

The connection between DIV and IAS is established during the DIV provisioning process in SAP for Me.

In SAP for Me, navigate to Systems & Provisioning → Provisioning

The Provisioning tab lists all systems that can be provisioned for the account. In the section “Systems to be Provisioned”, a Start Provisioning button is available (Figure 1).

Selecting this option initiates the provisioning workflow for DIV.

Figure 1: SAP for Me - Systems & Provisioning - Provisioning

During the provisioning process for DIV, an IAS tenant must be selected. The provisioning screen displays the available SAP Cloud Identity Services tenants. This might be the URL created during the previous blog article.

Typically, the default IAS tenant associated with the BTP global account is selected (Figure 2). Once confirmed, the provisioning request can be submitted. After a short processing time, the provisioning status changes from requested to provided. The DIV Provisioning Service becomes available and is automatically linked to the selected IAS tenant.

Figure 2: SAP for Me - Start New Provisioning Request

Step 2: IAS Application Created for DIV

As part of the provisioning process, an IAS application representing the DIV service is automatically created and linked to the corresponding BTP subaccount. This application functions as the technical anchor point for all authentication and authorization decisions related to DIV.

In the IAS Admin Console, this application appears under Applications & Resources, grouped under the relevant BTP subaccount (Figure 3).

Figure 3: DIV application automatically created in the IAS Admin Console and linked to the corresponding SAP BTP subaccount.

Step 3: Restricting Application Access in IAS

By default, IAS applications can be configured with different access modes. For enterprise DIV deployments, access must be restricted.

In the IAS Admin Console:

Open the DIV application (Figure 4)
Navigate to the Authentication and Access tab
Select Private access mode

The Private option ensures that:

Users cannot self-register
Only users explicitly imported or provisioned are allowed to authenticate

This setting is mandatory for controlled, enterprise-grade DIV deployments.

Figure 4: Configuration of application access mode for the DIV application in IAS

Step 4: Authorization Model for DIV

IAS enforces authorization separately for:

DIV Provisioning UI
DIV Wallet Tenants

This separation enables fine-grained access control and clear separation of duties.

DIV Provisioning Authorization

The following user groups are created in the IAS tenant by default:

DIV_Provisioning_Admin
DIV_Provisioning_Viewer

Only users assigned to these groups are able to access provisioning functions such as tenant creation, configuration, and user management.

DIV Wallet Authorization

For wallet access, IAS restricts users to specific wallet tenants. Even if authentication succeeds, access is denied if the user is not authorized for the requested tenant.

This prevents lateral access between departments or partner organizations in multi-tenant environments.

Step 5: Importing Users and Assigning Roles in IAS

Users must be explicitly imported into IAS and assigned to the appropriate DIV-related groups.

In the IAS Admin Console:

Navigate to Users & Authorizations
Select the DIV application
Choose Import Users and upload a CSV file (Figure 5)

The CSV file contains user attributes such as:

Status (mandatory)
First name
Last name (mandatory)
Email address (mandatory)
Group memberships

More CSV file attributes are listed and described on the SAP Cloud Identity Services help page.

An example CSV file includes a groups column containing DIV-specific roles (Table 1). These group assignments determine whether a user receives provisioning access, wallet access, or both.

Figure 5: User and authorization management for the DIV application in the IAS Admin Console, including user import via CSV

status	firstName	lastName	mail	groups
active	John	Doe	john.doe@sap.com	"DIV_System_Administrator, DIV_Application_Administrator"
active	Jane	Doe	jane.doe@sap.com	"DIV_Application_User"

Table 1: Example CSV file used to import users into IAS with assigned DIV-specific authorization groups

Step 6: Authentication and Access Enforcement

When a user attempts to access a DIV component, IAS performs an authorization check.

For example, when accessing the DIV Provisioning UI, the user is first redirected to IAS. The authentication screen displays the associated BTP subaccount and requests credentials (Figure 7).

Figure 7: IAS authentication and authorization check triggered when accessing the DIV Provisioning UI

Only if:

Authentication via the corporate identity provider succeeds, and
The user belongs to a group authorized for the requested application,

is access granted and the user redirected back to DIV.

Resulting Architecture and Security Model

After completing the steps described above, the following architecture and security characteristics are in place:

IAS acts as the single authentication entry point for all DIV components
Corporate identity providers remain the source of user identities
Authorization is centrally enforced through IAS groups and role assignments
Administrative and end-user access paths are clearly separated at the application level
Multi-tenant isolation is consistently enforced

The trust relationship between the SAP BTP subaccount and IAS is established during provisioning and configuration. At runtime, IAS issues authentication tokens containing group claims. These tokens are validated directly by the DIV applications based on the preconfigured trust.

The result is a secure, scalable, and enterprise-ready DIV setup aligned with real-world organizational structures (Figure 8).

Figure 8: High-level authentication and authorization flow for DIV using IAS

💡This concludes the three-part series on integrating SAP Cloud Identity Services – Identity Authentication with Decentralized Identity Verification.

⬅️ Go back to Creating and Accessing an IAS Tenant on SAP BTP (Part 2)

⬅️⬅️ Go back to Why IAS Is Essential for Enterprise DIV Implementations (Part 1)

Discovering the Power of SAP Cloud Identity Services with SAP Fieldglass

2026-01-28T14:03:44.923000+01:00

SAP Cloud Identity Services (SCI) is a central cloud identity suite on Business Technology Platform (BTP) that helps companies to easily manage users on-boarding and application services.

It offers comprehensive single sign-on and encryption across organizational and technical boundaries, but not only this. It’s comprised of a few different components, it’s a broader application that covers more than just single sign-on into applications.

Benefits to Using SCI

SAP Cloud Identity Services offer several benefits for managing identities, authorizations, and Single Sign-On (SSO) across cloud and on-premise solutions.

Key advantages include:

Seamless Single Sign-On: Provides a unified SSO experience across systems using standards like SAML 2.0 and OpenID Connect, simplifying user access to multiple applications.

Integration flexibility: Supports integration with both SAP and non-SAP systems, allowing for centralized user and group management.

Data persistence and privacy: Provides a central repository for managing users and groups while ensuring compliance with data privacy regulations.

One of SCI's main features is the Identity Authentication Service (IAS). This feature focuses on providing secure user access to applications, and it offers a range of tools to enhance security, such as password policies, multi-factor authentication, and risk-based authentication.

The Role of IAS

IAS plays a crucial role in critical areas, which are:

User management: IAS efficiently manages user accounts and disseminates user data to various SAP cloud applications, including SAP Fieldglass.
Login management: Every time users access the SAP Fieldglass URL, they are directed to the SAP IAS. This service then verifies the user’s identity either through single sign-on with the buyer’s own identity management system or by using a username and password.
Authentication: IAS facilitates the authentication process, ensuring that users are who they claim to be. This can be done through various methods such as passwords, biometrics, or tokens.
Authorization: Beyond just authenticating users, IAS also manages authorization by controlling access to resources based on user roles, attributes, and policies. This ensures that users can only access what they are permitted to.

Pre-requisites for IAS

In order to use IAS, you first need:

A BTP license

Bundles (a group of pre-configured products and services that are sold together)

Tenant Provisioning (SAP Fieldglass is automatically provisioned. This speeds up the entire process to get up and running)

Subscribing to SAP Cloud Identity Services

If you already have the SAP Fieldglass solution, you can start using SAP Cloud Identity Services at no extra cost by subscribing to it in the SAP Business Technology Platform.

See Identity Authentication Services (IAS) for SAP Fieldglass to learn how to subscribe to SCI and add the SAP FG application to SCI.

Integration

SAP is continually integrating SCI into an increasing number of its applications. This integration is crucial as SAP’s product suite evolves, ensuring centralized management of user profiles and streamlining the integration process with SAP’s offerings. You need to have SCI in order to use the following features:

Embedded Analytics and Analytics Add-on

SAP Analytics Cloud (SAC)

SAP Task Center

Joule

By integrating SCI, you gain access to Joule's intelligent automation capabilities, simplifying access to information and automating business processes, thereby enhancing productivity.

Joule uses Identity Authentication for user login and Identity Provisioning to manage user identities and their authorizations across various business applications.

The Identity Provisioning helps you provision identities and their authorizations to various business applications. It enables customers to set up faster and more efficient administration of user onboarding and offboarding, and its benefits are:

Automatic set up of user accounts and authorizations

Optimized for SAP cloud applications

The reuse of existing on-premise and cloud user stores

Jointly working with the SAP Identity Management product

Start Using SCI Today!

Do not miss all the benefits you can get using SAP SCI! It’s not just a tool for identity management, it’s a strategic asset that simplifies and enhances how you manage user profiles across your SAP cloud applications. By integrating SCI, you unlock numerous benefits, including cost-effectiveness, unified identity management, and simplified connectivity, ultimately leading to a more efficient and productive SAP environment.

See Also

What Are Cloud Identity Services

Configuration SAP Fieldglass SSO with SAP Cloud Identity Services Identity

Retrieving Users and Groups via SCIM: Integrating SAP Ariba with SAP Cloud Identity Services

2026-01-30T18:06:25.352000+01:00

SAP Ariba SCIM API

The SAP Ariba SCIM API is a REST API based on the SCIM (System for Cross-domain Identity Management) 2.0 specification. It is intended for use as an interface between SAP Ariba cloud solutions and SAP Cloud Identity Services to transfer user information as part of user management.

Prerequisites

To call the methods of this SAP Ariba SCIM API you must have SAP Ariba Procurement or Strategic Sourcing Realms.

ACCESS SAP Ariba APIs

1. Access SAP Ariba APIs : https://developer.ariba.com/api/home

2. Select the right Data Center where your SAP Ariba Realms located, in my case is Japan Data Center:

3. To find the API Specs, click Discover, fill the right solution, Procurement or Strategic Sourcing, search the page with SCIM API for User and Group Master Data and click.

4. Now we will request SCIM API. Go to Manage, click + to Create a New Application.

5. Fill necessary information and click submit:

6. Application created, you can click Action and then click Request API Access, then select the SCIM API and select SAP Ariba Realms that you want to retrieve data from. Then click Submit.

7. Screen shows as below and auto-Approval will happen in about 1 day:

8. Once approved, click Actions and click Generate Auth Secret. Note down them and will be used in API.

CALL SAP Ariba SCIM API

1. My personal preference is to test post and get in PowerShell and once it works ok, configure in Postman or Bruno to have a more filtered or formatted view of the result. Now open PowerShell:

2. Type below into powershell to post and get the Access_Token:

3. Enter and you will find the necessary access token and token type as below, note them down:

4. Now use the access token above to type below command, enter and all users will be listed as below:

Now all necessary info to call SCIM and retrieve user and group data is ready.

CALL SAP Ariba SCIM API in Bruno

1. Change to Bruno UI, create a new request, select Type as HTTP , fill Request Name , select URL with POST and fill the URL, then click Create.

2. Go to Headers, configure Content-Type as application/x-www-form-urlencoded.

3. Then go to params, configure below 3 attributes:

grant_type : client_credentials

client_id : Oauth Client Id

client_secret : Oauth Secret Generated

4. Run the request and note down the access_token:

5. Create a new request, select Type as HTTP , fill Request Name , select URL with GET and URL, then click Create.

6. Go to Headers, fill below four attributes:

Authorization : <token_type> <access_token>

apiKey : Application API Key

x-anId : Realm ANID *for test with -T

Accept : application/scim+json

7. Run the request, you can see more formatted data as below:

8. Based on the specs below, you can search more data with filters etc.

For example, you want to get User with email address equals below:

9. You can also retrieve all group data as below:

Identity Directory API (CIS - IdDS)

Manage users, groups and custom schemas in the cloud. Help Portal : https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/identity-directory-scim-rest-api

Prerequisites

To call the methods of this SCIM REST API you must have a system as administrator with an assigned Manage Users role.

API SPECS

Please find detailed API info from here : https://api.sap.com/api/IdDS_SCIM/overview

ACCESS Identity Directory API:

Make sure you are Administrator User in CIS - idDS:

1. Administrator can login to CIS via link : https://<Tenant ID>.accounts.ondemand.com/admin/

2. To check other Administrators, click and select as below:

3. Call API via PowerShell by typing as below, click enter and you will see all users.

-u UserID:Password

-H "Accept: application/scim+json" `

-H "Content-Type: application/scim+json"

4. Now use Bruno to get better formatted result. Create a Request as below:

5. Clich Auth, then select Basic Auth from dropdown list, Fill UserName and password with your Administrator(User) email address and password.

6. Click Headers, configure Accept and Content-Type as application/scim+json.

7. Execute and all users of CIS(IdDS) retrieved as below:

8. Add filter based on user Login Name, execute then you can see the user has been extracted:

9. You can also retrieve group data by filter as below:

Summary

This blog walked through how to retrieve user and group master data using SCIM 2.0 APIs from both SAP Ariba and SAP Cloud Identity Services (Identity Directory / IdDS)—a foundational requirement for user provisioning and synchronization scenarios.

Instead of introducing the full functionality of Identity Provisioning Service (IPS), the focus was placed on the practical API calls that IPS relies on internally: how to access the API specifications, request API access, authenticate, and retrieve users and groups using SCIM-compliant endpoints. Both PowerShell and Bruno were used to demonstrate how to call these APIs and inspect responses in a structured and readable way.

By understanding how SAP Ariba and Identity Directory expose identity data through SCIM—along with supported filters, attributes, and authentication mechanisms—you gain deeper insight into IPS properties, mappings, and transformations. This knowledge is especially critical when enabling SAP Ariba Joule, where accurate user and group synchronization across SAP Ariba, SAP Cloud Identity Services, and SAP Build Work Zone is essential.

In short, mastering these SCIM APIs is not just about calling endpoints—it is about building a solid foundation for reliable identity integration in SAP’s AI-driven and Business AI–focused landscape.

Custom Domain Service in SAP BTP Build Work Zone (Standard Edition)

2026-02-03T06:12:27.191000+01:00

Hello Everyone,

After analyzing and successfully implementing Custom Domain Service in SAP Build Work Zone, Standard Edition, I’m writing this blog to share my learnings. This post explains the concept of Custom Domain Service in SAP BTP and provides end-to-end steps to configure and use it with SAP Build Work Zone.

This blog will help you get started with SAP Custom Domain Service in SAP BTP Build Work Zone (Standard Edition).

Business Requirement

Our client required the use of a custom (client-specific) domain instead of the SAP standard domain.

By default, when accessing an SAP Build Work Zone site, the URL looks like this:

https://<SubAccount>.launchpad.cfapps.<DataCenter>.hana.ondemand.com/site/<site-alias>#Shell-home

(Here, we are using SAP Build Work Zone – Standard Edition.). We can use it for advanced edition too.

The requirement was to replace this with a client-friendly URL, for example:

https://abc.com  
OR  
https://abcservices.abc.com

We initially tried redirecting traffic from
https://abcservices.abc.com to the SAP BTP Work Zone URL.
However, this approach didn’t meet the requirement because:

Network-level redirection works, but
The browser address bar changes to the SAP BTP URL,
The client URL (https://abcservices.abc.com) is no longer visible.

To solve this, we implemented SAP Custom Domain Service.

Prerequisites

Before starting the configuration, ensure the following prerequisites are met:

1. Enable Custom Domain Service

Add Custom Domain Service to your subaccount with the Standard plan.

Note: Another plan exists but is deprecated at the time of writing this blog.

SAP Help Document:
https://help.sap.com/docs/custom-domain/custom-domain-manager/initial-setup

Below is the screen shot from sub account for reference:

Please note SAP will charge based on how many certificate you have uploaded in the Cusotm Domain Manager irrespective of Number of Custom Domain.

2. Finalize Reserved and Custom Domains

Finalize your reserved domain and custom domains in advance.

Do’s:

Do not rush this step.
Finalize domains separately for Non-Prod (DEV & QA) and Prod subaccounts.
Changing domains later can be complex and time-consuming.

Dont’s:

Do not signed the CSR form Trusted CA authority because it involved cost and time.
If possible dont configure the Non Prod and Prod Custom domain in single custom domain manager because it will mess the things. Try to keep the Custom Domain Service for Production seperately.
Dont configure the Custom Domain Manager for Production untill you get success in the Non Prod environment.

3. Runtime Destination Naming

Ensure the runtime destination names are finalized as per project standards, as these are referenced by applications.

Implementation Steps

Step 1: Define a Default Site

A default site is the site that opens when no site ID is specified in the URL.

Key points:

A default site is configured per custom domain.
It does not affect all domains in the subaccount.
A custom domain can be mapped to only one entry point, which is why it’s mapped to the default site and not to a specific site. Below is the screen shot of the default site:

Step 2: Identify the Reserved Domain

The reserved domain should be the parent domain, for example:

abc.com or abcservices.abc.com

The custom domain is created using the reserved domain, such as:

wz.abcservices.abc.com

Step 3: Define Custom Domains for Applications

Create custom domains for the following applications as needed:

SAP Build Work Zone
On-Premise Backend Systems (S/4HANA, CRM, BW, etc.) – Optional
Identity Authentication Service (IAS) – Optional

IAS works with the SAP standard domain by default. A custom domain for IAS is optional.

IAS Considerations

In our case, we did not configure a custom domain for IAS because:

IAS requires a separate CSR and CA-signed certificate.
This involves additional cost.
Wildcard certificates used in Custom Domain Manager do not work for IAS.

Reference Documents:

Step 4: Configure Custom Domain Manager

Add the reserved domain and custom domains in Custom Domain Manager.

Required Roles:

Assign the following roles to the user (Default or Custom IAS):

Custom Domain Administrator – Manage configurations
Custom Domain Viewer – View configurations

Once roles are assigned, you can access Custom Domain Manager from the subaccount.

Step 5: Create SaaS Routes

Create a SaaS route for each custom domain.
These routes act as redirection endpoints for:

SAP Build Work Zone
Backend systems (if applicable)

Step 6: Create TLS Configuration

Create a TLS configuration for secure communication.

SAP Help Document:
https://help.sap.com/docs/custom-domain/custom-domain-manager/manage-tls-configurations

Step 7: Generate CSR (Certificate Signing Request)

Generate a CSR from Custom Domain Manager and get it signed by a trusted Certificate Authority (CA).

CSR Generation Options

Option A: Individual Certificates
Generate one CSR per domain, for example:

s4.abcservices.abc.com
crm.abcservices.abc.com
bw.abcservices.abc.com

Option B: Wildcard Certificate
Generate a wildcard CSR:

CN: *.abcservices.abc.com  
SAN: *.abcservices.abc.com, abcservices.abc.com

Certificate Signing Guidelines

Internal network → Internal CA is acceptable and all the applicaiton will work.
Public access → Internal CA will cause browser warnings as below and navigation to the backend
Use a trusted CA like DigiCert if you want to access the custom domain publically.

Important Notes:

Verify CN and SAN before submitting CSR.
Certificates are valid only for the Custom Domain Manager instance from which the CSR was generated.
Non-Prod certificates cannot be reused in Prod.
We have generated the Wild Card Certificate for Production and Single Certificate (Included all SAN) for Non Prod System. Below is the Certificate Screen shot:

DigiCert Reference:
https://docs.digicert.com/en/certcentral/manage-certificates/reissue-an-ssl-tls-certificate.html

(Optional) IAS CSR Generation

Wildcard certificates do not work for IAS.
A separate CSR and certificate are required.

We skipped IAS custom domain due to additional cost and renewal overhead.

Step 8: Upload and Activate Certificate

Once signed, upload the certificate to Custom Domain Manager.

The certificate package includes:

Actual certificate
Intermediate certificate
Root certificate

Certificate Chain Format

Actual Certificate  
+ Intermediate Certificate  
+ Root Certificate

Tips:

Combine the full chain in a text file.
Remove extra spaces or blank lines.
Activate the certificate after upload.

Once activated:

Certificate expiry days are visible.
Renewal can be planned proactively.

Final Result

After successful activation, SAP Build Work Zone is accessible using the custom domain:

https://wz.abccompany.company.com

Errors that can occur: After all the configuration, If you stuck in the IAS authentication while accessing the work zone and getting the below error then add the custom domain in the IAS application:

Add you custom domain in the following path in the IAS if not came automatically:

Login to IAS -> Applications & Resources -> Applications -> Select the Application of Build Work Zone -> Single Sign On -> OpenID Connet Configuraiton and then in the Redirect URIs andPost Logout Redirect URIs section add the URl as https://*.abcservices.abc.ae/** (Your custom domain so that IAS will trust this domain)

Conclusion

I hope this blog helps you understand the Custom Domain Service concept and implement it successfully in SAP Build Work Zone projects.

Happy learning and implementing! 🚀

Regards,
Rohit Gera

AI Readiness: You don’t need an orchestra yet, you need a steady bass line

2026-02-05T19:01:46.690000+01:00

Any other big music fans in the procurement world out there? I know I am. And while I like music from most genres, what I really love is some intricate symphonic soul, like Isaac Hayes, or Curtis Mayfield. Strings, horns, keys, even a vibraphone. I get caught up in all the different sounds, the complex chords, how it all comes together. But a real groove needs a great bass line. If that one thing is off, the whole production feels wrong.

That’s how a lot of my customer conversations on AI in procurement feel lately. Everyone’s focusing on those extras – AI assistants, instant answers and insights, getting to talk to AI like a person, and shiny demos of the vast possibilities with SAP Joule. And while those things DO matter, and they are the end goal, without that steady bassline carrying us through, those other sounds won’t land the way they’re supposed to.

So what’s the bass line in SAP AI?

In SAP landscapes, a solid foundation comes down to a few important things.

Clean, consistent identity and access (IAS)
Reliable integrations and flows of data (BTP)
And, incredibly important, clear ownership and usable data in systems like Ariba

When identity is fragmented, data between systems becomes inconsistent, or processes start to vary depending on who’s involved and who’s taking action. When this happens, AI doesn’t become on-beat and insightful, it becomes…improvisational, like jazz (but not in the good way, more the kind that just feels like chaos). We need to feel the rhythm first, since procurement is often where we see issues show up first.

Maybe your suppliers don’t line up across systems. Or risk is managed in a separate system, and doesn’t connect to anything today. And, likely the most common thing we hear, users work around the process because it’s faster than doing it the right way.

These things aren’t always a technology problem, but more of a rhythm problem. Which is why building the foundation (bass line) is so important.

How are others laying down the groove and actually making progress? A few ways:

Standardizing across their SAP applications: This doesn’t mean everything has to be identical or locked down overnight. It usually starts much more simply: agreeing on how users authenticate, how suppliers are identified, and which system is the source of truth for what. When different SAP applications each have their own rules, logins, and data assumptions, things get out of sync fast. Standardization is what keeps the rhythm steady across the landscape instead of constantly drifting off-beat.
Building strong integrations through BTP: BTP is often talked about in very abstract terms, but in practice, this is about making sure data can move cleanly and predictably between systems. For procurement, this mostly means having supplier data flow consistently between Ariba and your ERP, risk info actually connecting back to suppliers, and integrations that are monitored and understood. When those integrations are brittle or one-off, that means AI is going to make guesses. We don’t want that.
Cleaning up supplier lifecycles and ownership in Ariba: Who owns onboarding? Who makes updates to supplier data? If you’re thinking, “It depends,” then that’s where problems likely start. Clarifying ownership of supplier lifecycles in Ariba doesn’t just improve data quality, rather it makes downstream automation and AI insights far more reliable.
Making processes easy enough that users can follow them: If a process is technically correct but painful in practice, users will work around it. Simplifying steps, reducing exceptions, and designing for how people actually work is part of the composition.
Policies in place that are actually enforced, both internally and with suppliers: Policies only help if they show up in the systems people use every day. When rules are enforced inconsistently (or not at all), data quality erodes, as does trust in the system.

That’s it, that’s the groove. Once you find this rhythm, the rest of the instruments can shine, take solos, and please a crowd. With that foundation, AI features become easier to adopt, and give better insights, and automation helps to reduce work, improve cycle time, ensure compliance, and other things you care about, instead of just confusing the people who actually have to use it.

Q4 2025 Quarterly Release Highlights: SAP BTP Security and Identity & Access Management

2026-02-10T09:00:00.021000+01:00

In the last quarter of 2025, we release a number of new features, as well as the SAP Key Management Service.

Want the full overview for SAP Cloud Identity Services? You’ll find a list of all new feature announcements for SAP Cloud Identity Services in the SAP Cloud Identity Services Release Notes on the SAP Help Portal.

SAP Cloud Identity Services: Use Data Control Language (DCL) to Define Authorization Policies

Developers define authorization policies in SAP Cloud Identity Services, using an SQL-like language - the data control language (DCL). Administrators can restrict base policies and combine authorization policies into a new authorization policy. For more details, please check the SAP Help Portal.

SAP Key Management Service

We released the SAP Key Management Service (KMS), which puts customers in control of their data across SAP cloud services and products. By managing their own encryption keys, customers decide exactly who can access their information.

With SAP KMS, data remains inaccessible to any external party, including SAP, government agencies, or legal authorities, unless the customer explicitly authorizes access. The service enables customers to securely create, manage, and control the encryption keys used to protect their data, and helps ensure that encryption and decryption can occur only with their approval.

SAP Cryptographic Library

The latest SAP Cryptographic Library release (version 8.6) supports quantum-safe cryptography and contains updated compliance certifications. It introduces a quantum-safe TLS 1.3 handshake using a hybrid key exchange that protects encrypted communications even against future quantum attacks.

In addition, SAP’s FIPS crypto kernel has achieved FIPS 140-3 certification, meeting strict security requirements for regulated industries. Together, these enhancements help customers future-proof their data protection while maintaining compliance. For more information, check our latest blog as well as release notes 3685428 - Fixes and features in CommonCryptoLib 8.6.2 and 1848999 - Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB).

Application Vulnerability Report for SAP BTP

Frequent security issues in open-source components endanger business data in applications. Use the application vulnerability report to detect and remediate any vulnerabilities in your SAP BTP landscape. The application vulnerability report focuses on detecting publicly-known security vulnerabilities based on Common Vulnerabilities and Exposures (CVEs). It's crucial to solve such vulnerabilities quickly as attackers are generally aware of them and might try to break into vulnerable systems. Check our blog for details.

Stay connected

Want to stay up to date on our services? Join our SAP BTP Security and SAP Cloud Identity Services communities!

Joule Studio Enablement Guide

2026-02-26T06:12:49.948000+01:00

📑 Table of Contents

Overview
Use Case & Mission Description
Prerequisites
Setting Up SAP Build for Joule Studio
Required Subscriptions & Instances in BTP
Mandatory Roles & Role Collections
Ensuring Required Subscriptions Are Available
Adding Missing Cloud Identity Service (Additional Tenant)
Formation Creation (Mandatory for Joule Integration)
Enablement Complete

1. Overview

Joule Studio is SAP’s platform to build Joule Agents, Joule Skills, and integrate enterprise AI capabilities directly into SAP applications. It is part of SAP Build, enabling teams to create and extend business applications and AI solutions with built-in governance and clean core alignment.

2. Use Case & Mission Description

Joule Studio is activated
Required BTP services are set up
Identity and trust between Joule and IAS are configured
Administrators can deploy Joule agents
Developers can create Joule Skills, Document Grounding, and integrate custom APIs

3. Prerequisites

To activate Joule Studio, the following must be fulfilled:

Required Entitlements

SAP Build Process Automation — Subscriptions(build_default)
Joule — Subscriptions(standard)
SAP Cloud Identity Services — Subscriptions(additional-tenant)

Cloud Identity Services (Mandatory)

IAS is required for:

Authentication
SSO
Authorization management
Trust configuration for Joule

If you do not have IAS, you must create a new tenant.

4. Setting Up SAP Build for Joule Studio

Standalone activation of:

Joule
SAP Build Process Automation

SAP BTP Boosters/Subscriptions

Boosters automate service activation.
Navigate:

Global Account → Boosters or Create Subscriptions of each of the plans given.

Use the following:

“Set Up SAP Build Process Automation”
“Set Up Joule”

Each booster/Subscriptions:

Assigns roles
Creates role collections
Subscribes necessary services

5. Required Subscriptions & Instances in BTP

Mandatory

Service	Plan	Required For
SAP Build Process Automation	build_default	Joule Studio backend
Joule	standard	Joule Studio AI
SAP Cloud Identity Services	Additional-Tenant	Authentication, SSO

6. Mandatory Roles & Role Collections

The Joule Booster does NOT create a role collection.

You MUST manually create one:

Create Role Collection

Subaccount → Security → Role Collections
Click Create
Name it: Joule_Role_Collection

Add Roles

Navigate to:
Security → Role Collections → Joule_Role_Collection → Edit

Add:

extensibility_developer
end_user

Save.

Assign to Your User

Security → Users
Assign: Joule_Role_Collection

7. Ensure All Required Subscriptions Are Visible in the Systems

Under:
Global Account → System Landscape → Systems

Confirm:

Joule (standard)
SAP Build Process Automation (build_default)
SAP Cloud Identity Services (Additional Tenant)*

(*) If missing, add manually (next section).

8. Adding Cloud Identity Service (Additional Tenant)

If IAS additional tenant is not visible:

Navigate:

Global Account → System Landscape → Systems → Service Owner View

Click Add System

Enter:

System Type: SAP Cloud Identity Services
System Name: any name
CLD Tenant ID: IAS tenant ID

Finding CLD Tenant ID

Use Cloud Reporting:

🔹 Live Landscape
https://reporting.ondemand.com/sap/crp/cdo?query=xxx&type=crp_search

🔹 Canary Landscape
https://spc-vlab.ondemand.com/sap/crp/cdo?query=xxx&type=crp_search

Replace xxx with your IAS tenant ID.

⏳Note: It may take up to 24 hours for reporting to sync newly created IAS tenants.

9. Formation Creation (Mandatory for Joule Integration)

Navigate:
Subaccount → System Landscape → Formations → Create Formation

1. General Information

Formation Name: Your Choice
Formation Type: Integration with Joule

2. Include Systems

Add:

SAP Build Process Automation
Joule
SAP Cloud Identity Services

3. Integration Details

Check the box:
Enable Capability Deployment

4. Create

System may take time (~10–30 minutes) to reach Ready status.

This deployment links Joule, BPA, and IAS together.

10. Enablement Complete — You Can Build Joule Agents

Once the Formation is Ready:

You can now:

Build Joule Agents
Build Joule Skills
Use Document Grounding
Call Custom APIs