SAP Community - SAP BTP Security

How to Integrate SAP BTP Cloud Logging Service with SAP Cloud Identity Services (IAS) Using SAML

2025-11-11T06:21:39.917000+01:00

Introduction

Why this matters: SAP Cloud Logging (based on OpenSearch) supports SAML 2.0 integration, allowing you to implement secure access and role-based authorization using SAP Cloud Identity Services (IAS) Groups.
While the official SAP Help documentation outlines the prerequisites and the JSON configuration for the Cloud Logging side, it does not detail the specific configuration steps required on the Identity Provider (IAS) side. This gap can lead to configuration errors, such as mismatched Entity IDs or missing attribute mappings. This article provides a complete, end-to-end guide to bridge that gap.
Benefits:
- Centralized Identity Management: Manage users and lifecycles in one place (IAS) rather than maintaining local users in OpenSearch.
- Single Sign-On (SSO): Provide a seamless login experience for developers and administrators across your BTP landscape.
- Security & Compliance: Adhere to SAP BTP security recommendations (BTP-CLS-0001) by enforcing MFA and audit logging via IAS.
Prerequisites:
- A Cloud Logging Service instance created in SAP BTP.
- An active SAP Cloud Identity Services (IAS) tenant with administrative access.
- Cloud Foundry CLI (cf CLI) installed to update the service instance.

Step 1: Prepare IAS for SAML Integration

In this step, we will register the Cloud Logging service as a Service Provider (SP) within IAS. This establishes the trust relationship required for authentication.

Log in to the IAS Admin Console: https://[tenant].accounts.ondemand.com/admin
Create a new SAML 2.0 Application:
This application represents your specific Cloud Logging instance.
- Application Name: CloudLogging-CLS-Test (You can choose any recognizable name).
Add SAML 2.0 Configuration:
We will configure the endpoints where IAS sends the authentication response.
- Select Configure Manually.
- SP Entity ID: cls-test
  Note: This ID must be unique within your IAS tenant and must exactly match the entity_id defined in your Cloud Logging JSON config later.
- ACS URL: https://[cls-url]/_opendistro/_security/saml/acs
  Note: The "Assertion Consumer Service" URL is where IAS posts the SAML token. You can find the base [cls-url] by checking the "dashboards-endpoint" in your BTP service key or instance details.
- Single Logout URL: https://[cls-url]
- Binding: HTTP_REDIRECT
- NameID Format: Email
  This ensures the user is identified by their email address in the OpenSearch audit logs.
Configure Attributes:
Crucial Step: Cloud Logging relies on SAML assertions to assign permissions. We must map the user's groups in IAS to an attribute named groups.
- Name: groups (This is the key Cloud Logging looks for).
- Source: Identity Directory.
- Value: All Groups (Or specific groups if you want to restrict the payload size).

Step 2: Create IAS Group for Admin Access

Instead of mapping individual users, we will use IAS Groups to manage permissions dynamically. This group will be mapped to the all_access role in Cloud Logging.

Group Name: LoggingAdmins
(Ensure this name matches the admin_group parameter in Step 4 exactly).
Assign the users who require full administrative access to the OpenSearch Dashboards to this group.

Step 3: Generate Signing Key and Certificate (Optional)

For enhanced security, you can configure Cloud Logging to sign its authentication requests sent to IAS. This proves the request actually came from your Cloud Logging instance. If you enable "Signed Authentication Requests" in IAS, this step is mandatory.

Run the following commands to generate the necessary keys:

# Generate a new private key and certificate
openssl req -x509 -newkey rsa:2048 -keyout private.key -out cert.pem -nodes -days 365

# Convert the key to PKCS#8 format (Required for the JSON config)
openssl pkcs8 -topk8 -v1 PBE-SHA1-3DES -in private.key -out private_pkcs8.key

# Encode the key to Base64 to fit into the JSON string
base64 -w0 private_pkcs8.key > private_pkcs8.b64

Upload the cert.pem file to the Signing Certificate section in your IAS Application.
Keep the private_pkcs8.b64 string ready for the Cloud Logging configuration in the next step.

Step 4: Configure Cloud Logging Service

Now we apply the configuration to the Cloud Logging instance. This tells the OpenSearch security plugin how to talk to IAS.

Create a JSON file named saml-config.json:

{
  "saml": {
    "enabled": true,
    "initiated": true,
    "idp": {
      "metadata_url": "https://<IAS-tenant>/saml2/metadata",
      "entity_id": "https://<IAS-tenant>"
    },
    "admin_group": "LoggingAdmins",
    "roles_key": "groups",
    "sp": {
      "entity_id": "cls-test",
      "signature_private_key": "<Base64-encoded-key>", // Optional: From Step 3
      "signature_private_key_password": "<password>" // Optional: If you set a password on the key
    },
    "exchange_key": "RandomKey32CharsRandomKey32Chars"
  }
}

Configuration Breakdown:

idp.metadata_url: The URL where Cloud Logging fetches IAS public certificates.
admin_group: Users belonging to this IAS group (LoggingAdmins) will automatically get super-admin privileges.
roles_key: Tells Cloud Logging to look at the groups attribute in the SAML assertion to find group memberships.
exchange_key: A random string used internally for cookie encryption (must be at least 32 characters).

Apply the configuration using the Cloud Foundry CLI:

cf update-service cls-test -c saml-config.json

Step 5: Validate the Integration

Once the update finishes, verify the setup to ensure the handshake between IAS and Cloud Logging is working correctly.

Open your Cloud Logging Dashboard URL: https://[your-cls-url]
You should be immediately redirected to the IAS login page.
Log in with a user that you assigned to the LoggingAdmins group in Step 2.
Upon successful login, check your user profile in OpenSearch. You should see that you are mapped to the all_access backend role.

Troubleshooting

If you encounter issues, check the following common errors:

400 Bad Request: This usually means the SP Entity ID in your saml-config.json does not match the Entity ID configured in the IAS Application. They must be identical. Also, verify the ACS URL in IAS matches your Cloud Logging URL exactly.
401 Unauthorized: You authenticated successfully, but don't have permission to view the dashboard. Verify that:
- The user is in the LoggingAdmins group in IAS.
- The Attribute mapping in Step 1 is set to groups.
Emergency Reset: If you lock yourself out, you can disable SAML to regain access via client certificates or default credentials:

cf update-service cls-test -c '{"saml":{"enabled":false}}'

Conclusion

You have successfully configured SAML 2.0 authentication for SAP Cloud Logging. By integrating with SAP Cloud Identity Services, you have moved from basic authentication to a robust, enterprise-grade identity solution.

Security: Centralized control reduces the risk of unauthorized access.
Scalability: Easily manage new team members by simply adding them to the IAS group.
Next Steps: Consider setting up additional groups in IAS and mapping them to specific "Read-Only" roles in OpenSearch for non-admin users.

I hope this article proves useful and helps you save time with your configuration!
Shusei Sekiya

SAP TechEd 2025 Virtual: Experience the best of SAP TechEd and broaden your SAP security expertise

2025-11-14T11:57:51.056000+01:00

You missed SAP TechEd Berlin? Don’t worry – we recorded many sessions for you, and they’re available free of charge on the virtual SAP TechEd platform.
Check out these three security sessions:

Road map for security and compliance services in SAP BTP (XP802v)
Rakefet Jackoby Galazan and Michael Friedrich lead you through the road map for security, identity and access management, and compliance services in SAP Business Technology Platform (SAP BTP). Learn about upcoming features and enhancements that boost protection, help ensure regulatory alignment, and support more-secure, scalable cloud architectures.

Insider threats: Security versus AI and analytics (CA100v)
Insider threats—whether intentional or accidental—continue to challenge organizations, demanding a proactive and adaptive defense strategy. Slim Trabelsi and Chase Kilburn dive into the design of a comprehensive insider threat program that integrates behavioral analytics and AI-driven monitoring to detect and mitigate risks effectively.

From control to confidence: What’s ahead for security and compliance at SAP (CA815v)
Sabrina Himmer and Patrick Boch give an outlook on future security features and tools within SAP Business Suite. Additionally, they dive into the streamlining process for compliance regulations that SAP and SAP Business Suite will adhere to now and in the future.

Join the SAP Security and the SAP TechEd Communities to stay up to date – and sign up for the monthly SAP Security Newsletter to get all the latest news delivered directly into your inbox!

How to secure your integration flows in SAP Integration Suite

2025-11-18T06:43:54.400000+01:00

SAP Integration Suite is basically SAP's way of letting you connect everything, from your old-school SAP systems to your cloud apps. Think of it as the super glue holding all your tech together.

It has tools like:

Cloud Integration (CPI) – for creating and handling iFlows
API Management – for handling, and guarding your APIs
Open Connectors – for third party integrations (like Salesforce, Google, etc.)
Integration Advisor – for making B2B connections easier

If you're using iFlows to send important business info, security has to be a priority from the get-go.

Why Protecting iFlows Matters

Your iFlows might be sending:

Customer info
Financial records
Employee details
Proprietary business logic

If those flows aren't secure, you could face:

Data leaks
Compliance violations (like GDPR, HIPAA)
System crashes or attacks

Unsecured integrations put your business at serious risk.

Key Areas to Focus On

1. Who Gets Access

Start by making sure only the right people can get to your iFlows.

I suggest:

Using OAuth 2.0 for secure API access with tokens
Using client certificates for connections between systems or B2B stuff

Don't:

Use basic authentication, especially with hardcoded passwords. If you still are, try to switch ASAP.

Also, give people the right roles. Use role-based access control in SAP BTP Cockpit and only give people the access they need.

2. Keep Things Encrypted

Use HTTPS with TLS 1.2 or higher for all data transfers.

For on-premise systems, use SAP Cloud Connector with a list of approved IP addresses and TLS.

For sensitive payloads, consider message-level encryption or PGP steps within your iFlow.

Avoid saving sensitive data unless you really have to. SAP encrypts data at rest by default, but you should still control what data you keep.

3. Design with Security in Mind

Security should be a normal part of your design, not something you add at the end.

Some good ideas:

Check all incoming data (use JSON/XML validator steps)
Clean up inputs used in Groovy or JavaScript
Avoid dynamically evaluating user inputs in scripts
Use content filters to block or route unwanted messages
Use the Groovy script sandbox to stop access to risky Java classes

4. Secure Your APIs

If you're exposing iFlows as APIs through SAP API Management, make sure to:

Use OAuth 2.0 or API key validation
Apply rate limiting and quotas
Enable IP filtering
Check incoming JWTs to maintain identity context
Use threat protection to stop XML/JSON injection attacks

5. Monitor and Track Everything

Enable logging and monitoring to spot problems early.

Use SAP Audit Log Service to track changes and access events.
Set up alerts for suspicious activity, like huge payloads or frequent errors.
Use SAP Cloud ALM or integrate with tools like Splunk or Dynatrace to see what's going on.

Logs and monitoring are key for fixing problems and proving you're following the rules.

A Real World Example

A factory accidentally exposed an iFlow with basic authentication info that was hardcoded. An attacker found it and got into confidential shipping data.

The problem went on for days because no one was watching or getting alerts.

The result was a data leak, fines, and a damaged reputation.

This shows why even small mistakes can lead to big trouble.

Secure DevOps

Security doesn't stop when you deploy.

Use SAP Transport Management Service (TMS) to move iFlows across environments with approvals
Keep secrets in the SAP BTP Keystore or Secure Parameter Store
Don't put passwords in scripts or config files
Automate testing, including tests for bad situations and security regression tests

Identity Propogation

In hybrid integrations, maintaining user identity across systems is important for audit trails and authorization.

Some options:

JWT tokens for cloud-based situations
SAML assertions for on-premise SAP systems
OAuth2SAMLBearerAssertion in SAP API Management for secure token exchange

Threat Modeling

Use the STRIDE model to identify risks in your integration design early:

1. Spoofing: Use OAuth 2.0, client certificates

2. Tampering: Use digital signatures, message hashing

3. Repudiation: Enable and retain audit logs

4. Information Disclosure: Use TLS, apply data masking

5. Denial of Service: Apply rate limiting, IP restrictions

6. Elevation of Privilege: Use role-based access control

Metrics to monitor

Track these things to see how secure you are:

Failed login attempts
Outdated or insecure connections
Hardcoded passwords in iFlows
How long it takes to fix problems
Time to react to security alerts

Use dashboards or connect to your SIEM tools to stay informed.

Security Checklist

Before you deploy an iFlow, make sure that:

1. HTTPS and TLS 1.2+ are enforced

2. Authentication is done with OAuth or certificates

3. No credentials are stored in scripts

4. Sensitive data is encrypted or hidden

5. Role-based access controls are set up

6. Monitoring and alerts are configured

7. API throttling and quotas are in place

8. Input validation and error handling are implemented

Helpful SAP guides:

SAP Integration Suite Security Guide: https://help.sap.com/docs/integration-suite#operate_task-security

Identity and Access Management: https://help.sap.com/docs/integration-suite/sap-integration-suite/identity-and-access-management?version=CLOUD

Final Thoughts

Security is more than just a setting. It's a way of thinking.

Whether you're building, designing, or taking care of iFlows, make security a daily habit. Check your integrations often. Look at your logs. Fix problems fast.

Because in today's connected world, your integrations are more than just tech. They're the foundation of your business. Keep them secure.

Project Foxhound - on the Scent of Client-Side Web Vulnerabilities

2025-11-19T11:10:41.188000+01:00

In this article, we show how the open-source Project Foxhound has evolved from its academic roots to become the best tool for discovering client-side security vulnerabilities.

The most recent development on this journey is that Foxhound was selected to appear as part of Black Hat Arsenal 2025 in London in December! If you are attending the conference, be sure to check out our demo, where we are hoping to reveal some exciting new features and integrations!

Background

The world-wide-web is one of the most pervasive innovations of the modern age, underpinning communications, banking, education and business. However, programming flaws or misconfigurations can cause security vulnerabilities, exposing the systems and their data to malicious attackers. According to a recent report from IBM, the average cost of a Cybersecurity data breach is $4.4M.

In recent years, web applications have seen a paradigm shift from on-premise, monolithic server applications, to heterogeneous collections of cloud-based microservices. As such, much of the application logic has shifted from the server to the client, with program logic running as JavaScript code in a user's browser. This shift has brought with it new classes of client-side (or DOM-based) web vulnerabilities, for example:

Client-Side Cross-Site Scripting (XSS)
Client-Side Cross-Site Request Forgery (CSRF)
Request Hijacking
Markup Injection

Most state-of-the-art tools, however, are still focused on detection of their server-side counterparts (such as reflected XSS). Hunting for client-side issues, remains a manual effort, requiring time-intensive and costly penetration tests.

Figure 1: JavaScript vulnerable to client-side XSS

Project Foxhound

This is where project Foxhound comes in – providing a state-of-the-art framework for the detection of client-side web application vulnerabilities. It has seen a wide range of proven use-cases, from academic studies to industrial-scale dynamic testing and even education.

Features

Foxhound is a modified web browser based on Firefox with the following enhancements:

An instrumented JavaScript engine and content model to track insecure data-flows using dynamic taint-tracking.
Taint tracking makes it possible to automatically detect client-side vulnerabilities by tainting certain attacker-controlled strings, e.g., location.hash, and notifying the user when tainted data reaches a sensitive sink, e.g., eval() or .innerHTML.
Foxhound also tracks a history of operations performed on the string at runtime, allowing automatic detection of potential input sanitization which essentially reduces false positives.
Integration with popular browser automation frameworks, such as Selenium and Playwright.

History

The technology for Foxhound was conceived at SAP Security Research back in 2013, where it was successfully used to discover that at least 10% of web applications are vulnerable to cross-site scripting. This paper spawned multiple follow-ups, with many research groups implementing their own instrumented browsers, which is not a trivial task!

We saw the need in the community for an open-source, up-to-date tool for teams to use as a platform for their own research. This gap was the main inspiration to open-source our implementation, which was released in 2022 – and Foxhound was born!

Since then, the Foxhound community has grown from the initial founders at SAP and the University of Braunschweig and is currently in use by groups at CISPA (Germany), Waterloo (Canada), and Venice (Italy). With the support of the SAP Open Source team, the project has evolved and matured, appearing in podcasts, at conferences, and even has a new logo!

Foxhound has also proven its worth in industry, with SAP using it to dynamically test UI5 applications since 2023 as part of the award-winning FioriDAST tool.

Why Foxhound?!

Foxhound offers several advantages over existing tools and techniques to outperform the competition. Firstly, as Foxhound uses dynamic testing, it benefits from lower false positives and higher accuracy compared to static analysis techniques. Secondly, Foxhound is non-invasive and does not require actively probing an application with potentially harmful and inaccurate payloads.

In fact, a recent independent academic study found that Foxhound was the best tool for dynamic JavaScript analysis. To quote the paper: "the only effective solution given the current state of the art is Project Foxhound."

Figure 2: Foxhound hard at work detecting a cross-site scripting vulnerability at https://domgo.at

Find out More

The next opportunity to experience Foxhound live and meet the team in person will be at Black Hat Europe, where Foxhound has been selected to appear as part of the Arsenal program. So be sure to pass by our booth to check out the latest features!

If you can’t make it to Black Hat, but are still interested in the project, check out the following links:

The best place to find out more is on our GitHub repository where we also manage development via issues and pull requests and actions.
Binaries for selected platforms are provided by the University of Braunschweig on a dedicated server.
More resources include academic papers, talks at IEEE S&P 2025 and the German OWASP day, and even a Podcast!

Authors of this Article

Thomas Barber, Product Security Expert, SAP BTP
Ulrike Fempel, SAP Open Source Program Office

Accessing BTP User Security Using APIs of the SAP Authorization and Trust Management Service

2025-11-19T11:59:58.410000+01:00

Introduction

Identity and Access Management lies at the core of an organization's Digital infrastructure. In SAP's BTP ecosystem, identities are provisioned in SAP Identity Services and roles are granted in BTP.

This blog aims to capture my learnings during my investigations to fetch Users and their assigned roles in BTP using APIs, which then can be later read to an Organization's IAM system for User lifecycle management.

I am targeting this API call to the BTP subaccount rather than the SAP IAS tenant as we were looking to not only interested in fetching the users in BTP but the assigned BTP roles as well.

Pre-requisite

You have BTP CLI installed. If not, you can download and install following the instructions from Download and Start Using the btp CLI Client | SAP Help Portal

Create a credential for API access

Create a credential to call he REST APIs of the SAP Authorization and Trust Management service. Credentials can be created on global account, subaccount, or directory level.

Log in to your BTP global account. Your first login takes you into a global account, and all your commands are executed on a global account level. In my case, I would like my commands to be executed on a specific subaccount, so do so by using the "btp target" command.

btp cli login

btp targetOnce you are in the desired BTP target, create the api-credential using command btp create security/api-credential --name my-credential

Store the these details in a secure location or password manager, as you will not be able to retrieve the client ID & secret later.

Call the API

We will test the API using Postman

We can use the different endpoints of the SAP Authorization and Trust Management service APIs to manage users roles and other authorization configurations

Actually, we need two separate URLs. First, you need the token URL to fetch an access token. Next, you can use the API URL to call an API.

To call an API of the SAP Authorization and Trust Management service, you need an access token. See the following example how to retrieve an access token and how to call an endpoint with GET request

Configure postman to request a token from the OAuth authorization server

Create a new collection from template "REST API basics". In the POST call, add the Token URL from the create API credential step. Add the below parameter to the post call.

Key	Value
grant_type	client_credentials

In the Authorization tab, select Auth Type "Basic Auth". In the Username & Password fields, enter the client ID & secret.\

Once you click send, the authorization server returns a token along with other related information

We can now use the value of this access_token property to make calls to the various API endpoints

With a GET request, we can now call the API end point to request the list of users and their details. With the Auth type selected to "Bearer Token" and paste the Token we received from the above step.

You can refer to Try Out | User Management (System for Cross-domain Identity Management (SCIM)) | SAP Business Accelerator Hub for other API endpoints for User Management.

Conclusion

To summarize, this blog's main goal was to document my learnings for a niche request where we would need to fetch a BTP subaccount User list and their assigned roles in BTP. I have used postman for testing the API calls for the purpose of this demonstration, but for a production scenario the 3rd party IAM system can connect to the BTP subaccount security in the same way. As I mentioned in the Introduction, I am targeting this API call to the BTP subaccount rather than the SAP IAS tenant as we were looking to not only interested in fetching the users in BTP but the assigned BTP roles as well. Hence, Ideally for user provision and management we can use another set of API calls targeting the SAP IAS Tenant

Based on interest, I may create another blog with steps for API calls to SAP IAS tenant for User Provisioning. Tenant management etc.

Introducing Application Vulnerability Report for Cloudfoundry Applications – Try It Now!

2025-12-02T08:25:25.852000+01:00

Application Vulnerability Report Service is currently in Beta Phase
Try it out and provide feedback on your observations
SAP Technical Support Ticket Component : BC-CP-SEC-AVR

What Is Application Vulnerability Report?

Security is a top priority in today’s digital landscape, especially when applications rely heavily on open-source components. These components, while powerful and cost-effective, often come with publicly known vulnerabilities that can put your business data at risk.

The Application Vulnerability Report is a newly introduced feature for SAP Business Technology Platform (BTP) services that helps you detect and remediate vulnerabilities in your Cloud Foundry applications. This tool scans your application for known security issues based on Common Vulnerabilities and Exposures (CVEs), ensuring that you stay ahead of potential threats.

Currently in Beta Phase and available in eu-10 region.. Once Beta Phase is completed.. roll-out to other regions are expected in Q1 or Q2 2026.

How to enable in your tenant ?

Go to Entitlements in your SAP BTP Sub-account to add Application Vulnerability Report to add the plans

Service Marketplace

Search for application-vulnerability-report-service in the SAP BTP Service Marketplace

Create Instance in your Cloud Foundry space

Go to your Cloud Foundry Space (example : Dev, UAT, TST...etc)
Create a new Instance for Application Vulnerability Report with default plan
Provide a Instance Name

Create Service Key

Create a New Service Key for API Access

Allow the User to Access the Space

You need to manually add the application-vulnerability-report-scanner@sap.com user to your Cloud Foundry space. This enables the application vulnerability report to download the droplets of the respective applications and scan them accordingly.

Log on to the CF space that you want to scan.
Select the Space Members tab and choose Add Member.
Enter the application-vulnerability-report-scanner@sap.com user and assign the Space Auditor role to it.

Why Is This Important?

Open-source vulnerabilities are one of the most frequent security challenges in modern application development. Attackers are quick to exploit these weaknesses, and failing to address them promptly can lead to severe consequences, including data breaches and compliance violations.

By using the Application Vulnerability Report, you can:

Identify vulnerabilities early in your application lifecycle.
Understand the severity of each issue based on CVE data.
Take corrective actions quickly to secure your SAP BTP landscape.

Application Vulnerability Report - Process overview

The application vulnerability report supports you in the detection of vulnerabilities in custom applications during runtime. Instead of a shift-left support approach during pipeline runs, this service provides security-relevant information for what has already been deployed (and maybe forgotten). The service scans the applications using a proprietary scanning layer that utilizes open-source scanners such as Open Source Vulnerabilities (OSV) and trivy, as well as custom SAP BTP-specific and 0-day exploit targeted scanners. This unique combination offers a very broad and up-to-date coverage of vulnerabilities in your applications. By using an API, you can integrate the report data into your incident and security workflow.

Overview of the each Process flow

1. Applications Running on SAP BTP

This is the starting point.
It includes all your Cloud Foundry applications deployed on SAP Business Technology Platform.
Example : CAP, Python, Javascript, Java, Go, Dot-Net... any programming languages those are deployed in your Space.. (This also includes NPM Libraries, Pip libraries or any libraries which are consumed in your applications)
These applications often use open-source libraries and packages, which can have vulnerabilities.

2. Scanning Layer

This layer performs the security scans on your applications. It's currently runs weekly scan. It consists of multiple scanning sources:

Commercial
Uses commercial vulnerability databases and tools to identify known issues.
Trivy/OSV
Trivy is an open-source vulnerability scanner, and OSV (Open Source Vulnerabilities) is a database of vulnerabilities in open-source software.
These help detect issues in widely used open-source components.
BTP Specific
Scans for vulnerabilities specific to SAP BTP services and configurations, ensuring platform-level security.
0 Day
Focuses on zero-day vulnerabilities, which are newly discovered and not yet patched.
These are critical because attackers often exploit them quickly.

3. Application Vulnerability Report for SAP BTP

After scanning, all findings are consolidated into a single report.
This report provides:
- List of vulnerabilities
- Severity levels
- Recommendations for remediation
It acts as a centralized dashboard for security insights.

4. API for Customers

Customers can access the report via API.
This allows integration with:
- Security dashboards
- CI/CD pipelines
- Monitoring tools
Ensures automation and continuous security checks.

5. Customers

End-users (developers, security teams) consume the report and take corrective actions to secure applications.

Technical Usage

How to get findings of your deployed CF applications running.

Example : Scanned Finding Report

Reference:

External resource:

OSV database

Securing CAP Applications with SAP Cloud Identity Services and AMS

2025-12-04T05:52:08.244000+01:00

Introduction

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. SAP Cloud Identity Services is the central solution for managing authentication, Single Sign-On (SSO), and the identity lifecycle. They improve system integration, provide a seamless user experience, and enhance security and compliance.

The SAP Cloud Identity Services consists of four services:

Authorization Management Service(AMS) and CAP

The Authorization Management Service (AMS), as part of SAP Cloud Identity Services (SCI), provides libraries and services for developers of cloud business applications to declare, enforce and manage instance-based authorization checks. When used together with CAP the AMS "Policies” can contain the CAP roles as well as additional filter criteria, for instance, based authorizations that can be defined in the CAP model. transformed to AMS policies and later on refined by customer users and authorization administrators in the SCI administration console, and assigned to business users.

Use AMS as Authorization Management System on SAP BTP

For newly built applications, the usage of AMS is generally recommended. The only constraint that comes with the usage of AMS is that customers need to copy their users to the Identity Directory Service as the central place to manage users for SAP BTP applications. This is also the general SAP strategy to simplify user management in the future.

CDS-Based Authorization

Authorization means restricting access to data by adding respective declarations to CDS models, which are then enforced in service implementations. By adding such declarations, we essentially revoke all default access and then grant individual privileges.

Solution Diagram

Integrate With the Authorization Management Service into CAP Application

CAP is tightly integrated with Authorization Management Service (AMS). Applications that run with IAS-based authentication can benefit from AMS, which allows central access to policy management at the business level. The integration with AMS comes as an easy-to-consume plug-in for CAP applications.

The following section describes how to integrate your CAP application with the Authorization Management Service (AMS) using SAP Cloud Identity Service(IAS) as the identity provider.

You will be using cds add ams command to add the necessary dependencies and configurations to your CAP project.

The cds add ams automatically adds required configuration for IAS/AMS, considering the concrete application context (tenant mode and runtime environment, and so on).

cds add ias - adds configuration for authentication via IAS
cds add ams - adds configuration for authorization via AMS

Configure AMS Integration in CAP Application

For this blog, I will be using Incident Management Applicaiton: https://github.com/SAP-samples/incidents-app

Execute the following command to add IAS and AMS configuration and dependencies to your project:

cds add ams

Install the added dependencies:

npm i

Build the project:

cds build --production

The build command generates the DCL files in the ams/dcl/cap/basePolicies.dcl and gen/policies/dcl/cap/basePolicies.dcl folder. The generated policies will look like this:

POLICY "admin" {
	ASSIGN ROLE "admin";
}

POLICY "support" {
	ASSIGN ROLE "support";
}

The roles defined in processor-service.cds -> annotate ProcessorService with @(requires: 'support'); has the corresponding policy support generated in the DCL file. Similarly, the admin role is also generated.

Now, you can see that in gen/srv/ams/dcl/cap/basePolicies.dcl a policy support is generated. A user with the policy cap.support can view and update the Incidents.

Configure Users for Local Testing

The authorization checks that you added to the CAP model apply not only when deployed to the cloud but also for local testing. Therefore, we need a way to log in to the application locally. To test it, let's first add a wrong policy to the user alice, to access incidents, support role is required, so we will assign the admin policy to the user alice to see the authorization error:

Update the following configurations for the users in the package.json with the following code:

"users": {
    "alice": {
      "policies" : [
          "cap.admin"
      ]
    },
    "bob": {
    }
}

Open the application in your browser http://localhost:4004/webapp/incidents and log in with username as alice, leave the password field empty.

You should see an authorization error when trying to access the Incidents application because the user alice has the admin policy assigned, which does not allow access to the Incidents service.

[error] - 403 - Error: Forbidden
    at requires_check (/Users/xxxxxxxxxxx/incidents-app/node_modules/@sap/cds/lib/srv/protocols/http.js:54:32)
    at http_log (/Users/I329347/Coding/Dev-GuideQ4/incidents-app/node_modules/@sap/cds/lib/srv/protocols/http.js:42:59) {
  code: '403',
  reason: "User 'alice' is lacking required roles: [support]",
  user: User {
    id: 'alice',
    roles: { admin: 1 },
    policies: [ 'admin' ],
    authInfo: IdentityServiceSecurityContext { config: {} },
    is: [Function (anonymous)],
    amsRoles: [],
    [Symbol(AMS_AUTHORIZATIONS)]: Authorizations {
      ams: [AuthorizationManagementService],
      policySet: [Object],
      context: [EventContext],
      correlation_id: 'c9f8470e-59a5-xxxxx-9af8-8f5ed57a785b',
      defaultInput: [Object],
      authorizationLimits: []
    }
  },
  required: [ 'support' ]
}

This shows that the AMS integration is working correctly, as the user alice is missing the required support role to access the Incidents service.

Update the user alice in the package.json to assign the correct policy and test, you should be able to access the Incidents application:

"users": {
    "alice": {
      "policies" : [
          "cap.support"
      ]
    },
    "bob": {
    }
}

This demonstrates how you can use AMS in a CAP Application, for deployment to production and SAP Build Work Zone Setup you can read further here: https://github.com/SAP-samples/btp-developer-guide-cap/tree/main/documentation/xsuaa-to-ams

Wrap-Up

Integrating AMS into your CAP application is more than a technical enhancement — it positions your solution firmly within SAP’s modern identity and access management strategy.

With CAP’s streamlined tooling — cds add ams — developers can generate authorization policies directly from CDS models, enforce them consistently across environments, and support both role-based and instance-based access. Administrators benefit from unified policy management in the SCI console, while users enjoy a seamless and secure experience powered by IAS authentication and Identity Directory–based user management.

Beta Version of Application Vulnerability Report for SAP BTP Now Available

2025-12-04T14:18:40.970000+01:00

Earlier this month, we released the application vulnerability report (beta) for SAP Business Technology Platform (SAP BTP). You can use this new service to detect and remediate open-source application vulnerabilities in your SAP BTP deployed applications.

What is this new service all about?

Frequent security issues in open-source components endanger business data in customer deployed applications. Customers are responsible for performing vigilant patch and vulnerability management. By leveraging the new application vulnerability report for SAP BTP, open-source vulnerabilities in your Cloud Foundry applications can be detected and remediated. It's crucial to fix such vulnerabilities quickly, as attackers are usually aware of them and might try to break into vulnerable systems.

What does the new application vulnerability report service offer you?

The application vulnerability report supports you in the detection of vulnerabilities in custom applications during runtime. It enables you to act on criticality and other provided vulnerability details, like mitigation recommendations.

If we take a closer look at the process, the service scans the applications using a proprietary scanning layer that utilizes open-source scanners as well as custom SAP BTP-specific and 0-day exploit targeted scanners. This unique combination offers a very broad and up-to-date coverage of vulnerabilities in your applications. By using an API, you can also integrate the report data into your incident and security workflow.

Let’s have a quick look at the architecture overview:

Application Vulnerability Report for SAP BTP – Architecture Overview

Get started now!

You can find lots of useful information in this practical hands-on blog post:

Introducing Application Vulnerability Report for Cloud Foundry Applications – Try It Now!

The complete documentation is available on SAP Help Portal.

Please note that this is a beta service available on SAP BTP for subaccounts in trial and enterprise accounts. It is currently available in the “cf-eu10” landscape. Once the beta phase is completed, we plan to roll out the service to other regions.

If you are interested in what’s more to come, check out the road map in SAP Road Map Explorer.

Try it out, and we look forward to your feedback!

Also make sure to join our community to learn more about the security services and features in SAP Business Technology Platform here:

https://community.sap.com/topics/btp-security

Automating User Offboarding in SAP BTP Across Multiple Subaccounts with PowerShell & BTP CLI

2026-01-01T05:43:28.335000+01:00

Managing user offboarding in a complex SAP BTP (Business Technology Platform) landscape with multiple subaccounts can quickly become a time-consuming and error-prone process. Manually tracking and deleting users across all subaccounts and trusted identity providers (IDPs) increases the risk of missing accounts, leading to potential security gaps.

To address this challenge, I have developed a PowerShell script that automates the process of deleting users from all IDPs across all your BTP subaccounts, ensuring a secure and consistent offboarding process.

In this blog, I will walk you through the prerequisites, setup, and usage of the script, as well as the benefits it brings to your BTP user management.

Why Automate User Deletions?

SAP BTP tenants frequently use multiple subaccounts for different environments (dev/test/prod), business units, or regions. Each subaccount might rely on several identity providers (IDPs), making manual user cleanup a tedious and risky task. Automation ensures that:

No user is accidentally missed during the offboarding process.
Audit logs are maintained for all deletions, enhancing traceability.
The process is standardized and efficient, reducing manual interventions and errors.

Prerequisites

Before you begin, make sure you have the following:

SAP BTP CLI Installed
Download the SAP BTP CLI from [SAP Help Portal](https://help.sap.com/docs/btp/sap-business-technology-platform/download-and-start-using-btp-cli-client). Unzip it into a directory of your choice, e.g., `C:\BTP`.
Subaccount Administrator Role
You need to have sufficient permissions to manage users and IDP configurations in the target BTP subaccounts. Make sure your user has the **Subaccount Administrator** role in BTP.
PowerShell (Windows OS)
The script is written for PowerShell and assumes you are running on a Windows machine.
User Email List
   Prepare a text file named `useremails.txt` containing one email address per line for users you wish to offboard. Lines starting with `#` and empty lines are ignored by the script. Example:
   abcd.ytr@sap.com
   lmno.pqr@sap.com
   xyza.bcde@sap.com

Folder Structure

Place the following files in the C:\BTP directory. Alternatively, you can choose any location, as long as all the files listed below are stored together in the same folder.

`btp.exe` (SAP BTP CLI executable)
`delete-user-from-all-idps-txt-input.ps1` (PowerShell script - see below)
`useremails.txt` (Text file with user emails to be deleted)

Script Walkthrough

1. Logging Into BTP CLI

First, you need to authenticate using the BTP CLI. Open a CMD window and enter:

cd C:\BTP
btp login

***When prompted, enter the CLI server URL as: https://cli.btp.cloud.sap

2. Executing the Deletion Script

After logging in, Open Powershell Window and again change the folder to C:\BTP and run the PowerShell script with the following command:

.\delete-user-from-all-idps-txt-input.ps1 -UserEmailFile "useremails.txt"

On successful deletion

**What does the script do?**
- Reads the list of user emails from your `useremails.txt` file.
- Fetches all subaccounts your user has access to.—creates a file
- For each subaccount:
- Retrieves all trusted IDPs—creates a file
- Attempts to delete each user email from every IDP (including `sap.default`, the default identity provider).
- Logs the result (success or error) for every attempt.—creates a file
- Generates a timestamped log file for traceability.

3. Script Features

Bulk User Deletion: Delete multiple users from all IDPs across all subaccounts in one go.
Automatic Audit Logging: Each run creates a log file in the `C:\BTP` folder (e.g., `user_deletion_log_20251229_153201.txt`) recording every deletion attempt, including timestamp, subaccount, IDP, user, and outcome.
Intelligent Parsing: The script skips commented and empty lines in your email input file and robustly parses the BTP CLI output.
Error Handling: If a user is not found or cannot be deleted, it's clearly logged with an error message.

Conclusion

Automating user deletions with a PowerShell script and BTP CLI simplifies the offboarding process, reduces mistakes, and improves auditability in large BTP environments. Simply update your `useremails.txt` for each offboarding round, and in a matter of minutes, you can ensure all relevant user accounts are purged from every subaccount and IDP.

**Happy automating!**

PowerShell Script Code as below :

param (
[Parameter(Mandatory = $true)]
[string]$UserEmailFile
)

# --- CONFIGURE LOG FILE PATH HERE ---
$now = Get-Date -Format 'yyyyMMdd_HHmmss'
$LogFile = "user_deletion_log_$now.txt"

# Prepare log file with header
$logHeader = "User Deletion Log - Started at $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')"
Set-Content -Path $LogFile -Value $logHeader

function Write-Log {
param (
[string]$Message
)
Write-Host $Message
Add-Content -Path $LogFile -Value $Message
}

# Get the current user running the script
$scriptUser = $env:USERNAME
if (-not $scriptUser) { $scriptUser = $env:USER }

# Check if file exists
if (!(Test-Path $UserEmailFile)) {
Write-Log "ERROR: File '$UserEmailFile' not found."
exit 1
}

# Read user emails (ignore empty/comment lines)
$UserEmails = Get-Content $UserEmailFile | Where-Object { $_.Trim() -ne "" -and -not ($_ -like "#*") }

if ($UserEmails.Count -eq 0) {
Write-Log "No user emails found in the file."
exit 1
}

Write-Log "Read $($UserEmails.Count) user emails from $UserEmailFile..."

# Step 1: Fetch all subaccounts
Write-Log "Fetching subaccounts..."
.\btp list accounts/subaccount > subaccounts.txt

# Skip the header lines (assume first 2 lines are header and column desc)
$lines = Get-Content subaccounts.txt | Select-Object -Skip 2

foreach ($line in $lines) {
# Skip header/footer/blank lines
if ($line.Trim() -eq "" -or $line -match '^subaccount id:' -or $line -match '^subaccounts in') { continue }

# Split line by 2+ spaces (columns are separated by several spaces)
$fields = $line -split '\s{2,}'
if ($fields.Length -lt 2) { continue }

$subGuid = $fields[0].Trim()
$displayName = $fields[1].Trim()

Write-Log "`nFetching IDP trusts for subaccount: $displayName ($subGuid)..."
.\btp list security/trust --subaccount $subGuid > idp_trusts.txt

$trustLines = Get-Content idp_trusts.txt | Select-Object -Skip 1
$originKeys = @()
foreach ($trust in $trustLines) {
$trust = $trust.Trim()
if ($trust -match '(?<OriginKey>([a-zA-Z0-9\.\-]+|sap\.default))\s+(Active|Inactive)$') {
$originKey = $matches['OriginKey']
if ($originKey -and ($originKeys -notcontains $originKey)) {
$originKeys += $originKey
}
}
}

if ($originKeys.Count -eq 0) {
Write-Log "No origin keys found for subaccount $displayName ($subGuid)."
continue
}

foreach ($origin in $originKeys) {
foreach ($userEmail in $UserEmails) {
Write-Log "Deleting user $userEmail from origin $origin in subaccount $displayName ($subGuid)..."
.\btp delete security/user $userEmail --of-idp $origin --subaccount $subGuid
$timestamp = Get-Date -Format 'yyyy-MM-dd HH:mm:ss'
if ($LASTEXITCODE -eq 0) {
Write-Log "SUCCESS: User $userEmail deleted from subaccount $displayName, origin $origin by $scriptUser at $timestamp."
} else {
Write-Log "ERROR: User $userEmail not found, failed to delete User $userEmail from $displayName, origin $origin by $scriptUser at $timestamp."

}
}
}
}

Write-Log "`nDONE! User deletions attempted for all specified emails in $UserEmailFile, for all origins and all subaccounts."

How to Export All Users (with Origins) from All SAP BTP Subaccounts via CLI Automation

2026-01-02T08:17:57.154000+01:00

Introduction

If you manage a large SAP BTP Global Account, you may find it challenging to export a full user inventory—especially when your environment is segmented into multiple subaccounts and utilizes various identity provider origins (multiple trusts). The SAP BTP Cockpit does not offer a single "Export All Users" button at the global account level.

This blog demonstrates how to efficiently extract all users and their identity origins across all BTP subaccounts using the SAP BTP Command Line Interface (btp CLI) and PowerShell scripting.

Prerequisites

btp CLI: Ensure you have downloaded and installed `btp.exe` (the SAP BTP CLI). [Download Link]
Login Required: Log in to your SAP BTP Global Account using the CLI: btp login
Open a CMD window and enter:

Permissions: Your user should have sufficient permissions (Global Account Admin, Directory Admin, Subaccount Admin) to view users in the target scopes.
Windows PowerShell: The script example uses PowerShell, but similar logic can be implemented in Bash or Python.
Working Directory: Place your files in `C:\BTP` (or another folder of your choice).

Folder Structure

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

Secure SAP–AI Integration Using Advantco OpenPGP Services

2026-01-22T18:25:33.866000+01:00

Secure SAP–AI Integration Using Advantco OpenPGP Services

1. Purpose and Scope

This article defines a secure, deployment-agnostic reference architecture for integrating SAP backend systems with external AI agents using OpenPGP-based cryptographic services provided by Advantco. The architecture separates cryptographic processing from data transport, ensuring that encryption, decryption, signing, and verification are performed by a dedicated cryptographic service layer, while message routing and orchestration remain the responsibility of the calling application or integration layer.

The architecture is intended for hybrid enterprise environments in which SAP backend systems may be deployed on-premise, in private cloud, on hyperscalers, or under RISE with SAP. AI agents may run on external platforms or managed AI services. Advantco OpenPGP services are exposed as APIs (REST and/or SOAP) and may be deployed on SAP Business Technology Platform or an equivalent enterprise runtime. This document describes a logical reference architecture and does not prescribe a specific deployment topology.

The scope of this document is limited to secure data exchange and trust establishment between SAP systems and AI agents. AI model behavior, prompt engineering, SAP business logic, and transport-level protocol selection are out of scope except where they affect security guarantees.

2. Architectural Rationale

Integrating SAP systems with external AI capabilities introduces a trust boundary between SAP-controlled environments and systems that operate outside SAP governance. This architecture addresses that boundary by enforcing message-level security that is independent of transport mechanisms and network topology.

Rather than embedding cryptographic logic into SAP applications or integration flows, the architecture externalizes OpenPGP operations into a dedicated cryptographic service layer. This allows encryption, decryption, signing, and verification to be centrally governed, audited, and evolved without requiring changes to SAP business applications. Transport and routing of messages remain the responsibility of SAP applications or integration components, preventing the cryptographic services from becoming an implicit integration broker.

3. Architectural Overview

The architecture consists of four logical concerns: SAP backend systems, an optional integration or orchestration layer, Advantco OpenPGP cryptographic services, and an external AI agent ecosystem.

SAP backend systems produce and consume business data but do not perform cryptographic operations directly. They rely on an integration or orchestration layer such as SAP Integration Suite, a SAP BTP application, or other middleware to coordinate message exchange with external systems where required.

Advantco OpenPGP services provide cryptographic transformation via APIs only. They do not perform message routing, transport, or forwarding.

External AI agents receive only signed and encrypted payloads and return responses in signed and encrypted form. Unencrypted payloads exist only within SAP-controlled trust boundaries.

Advantco OpenPGP provides cryptographic APIs only and returns results to the caller. Message transport and routing are handled by SAP or integration components and are not performed by Advantco.

4. Architecture Structure

From a business perspective, the architecture enables SAP processes to consume AI-generated insights without relinquishing control over data confidentiality or trust decisions. AI systems may influence SAP outcomes, but only after cryptographic validation and SAP-side authorization.

From an application perspective, the architecture separates responsibilities clearly. SAP backend systems focus on business logic. The integration or orchestration layer handles routing, retries, and protocol adaptation. Advantco OpenPGP services handle cryptographic transformation. AI agents handle AI processing only.

From an integration perspective, communication is message-based and transport-agnostic. Payload-level security is applied using OpenPGP before data crosses trust boundaries, ensuring that transport security is an additional layer rather than the primary protection mechanism.

From a data perspective, unencrypted payload exists only within SAP-controlled environments. Outside those boundaries, data is always exchanged in signed and encrypted form, accompanied by cryptographic metadata required for verification and audit.

5. Component Responsibilities

SAP backend systems remain the authoritative producers and consumers of business data. They initiate outbound requests and consume inbound results but delegate cryptographic processing to external services. SAP systems do not store or manage cryptographic private keys.

The integration or orchestration layer (where present) is responsible for transport, routing, protocol handling, retries, correlation, and error handling. It invokes Advantco OpenPGP APIs as required and forwards encrypted payloads to external AI agents, and returns verified payloads to SAP systems. It does not perform cryptographic operations beyond invoking the cryptographic service APIs.

Advantco OpenPGP services provide cryptographic operations as APIs. For outbound processing, they accept payloads and perform optional compression, message digest generation, digital signing, and OpenPGP hybrid encryption. For inbound processing, they accept encrypted payloads, verify digital signatures, decrypt content under governed key controls, and return verified payloads to the caller. These services are stateless with respect to message routing and do not forward data to external systems.

External AI agents operate outside the SAP trust boundary and are treated as untrusted by default. They can only process data that they have successfully decrypted and verified using trusted SAP public keys. AI agents sign and encrypt all outbound responses using their own private keys and do not receive access to SAP private keys or verified SAP payloads.

Key management is handled by a centralized Key Management Service that governs cryptographic key lifecycles, enforces usage policies, and records audit events. Agent identities are established by registering and allow-listing agent public keys, typically identified by fingerprints or key identifiers. Private keys remain protected and are never exposed outside the cryptographic service boundary.

6. Message Exchange

The Advantco OpenPGP APIs may be invoked directly by SAP applications or by an intermediate integration or orchestration layer. In all cases, Advantco performs cryptographic transformation only and does not forward messages.

In the outbound flow, SAP backend systems submit payloads for signing and encryption via the Advantco OpenPGP service. The service returns a signed and encrypted payload to the caller, which is responsible for forwarding the encrypted message to the external AI agent.

In the inbound flow, the external AI agent produces a signed and encrypted response. The encrypted response is submitted to the Advantco OpenPGP service for verification and decryption. The service returns a verified payload to the caller, which delivers the result to the SAP backend system.

The sequence diagram above illustrates the strict request–response nature of the Advantco OpenPGP APIs and the separation of cryptographic processing from message transport and routing.

7. Trust and Security Model

Trust in this architecture is based on cryptographic identity rather than network location. Public-key identities establish which parties may exchange data, while centralized key governance determines how keys may be used. By default, no shared secrets are required between SAP systems and AI agents.

Confidentiality is enforced through OpenPGP hybrid encryption. Integrity and authenticity are enforced through digital signatures. Auditability is provided through centralized logging of cryptographic operations. Replay protection is enforced by the receiving side using message identifiers, timestamps, and validity windows.

Cryptographic validity does not imply business authorization. AI-generated responses or instructions must still be validated against schemas, allow-listed actions, and SAP-side authorization rules before affecting SAP business processes.

8. Deployment Considerations

The architecture supports a wide range of deployment models, including scenarios in which SAP systems and integration components run on SAP BTP while cryptographic services are cloud-hosted and AI agents operate on external platforms. Security and correctness depend on logical separation of responsibilities rather than physical co-location.

As a concrete implementation option, Advantco OpenPGP services are available for deployment on SAP Business Technology Platform (SAP BTP). In this model, the cryptographic services run as managed applications or services on SAP BTP and expose OpenPGP functionality through REST and/or SOAP APIs. SAP backend systems and SAP integration components can invoke these APIs directly using standard SAP-supported connectivity mechanisms. Deployment on SAP BTP does not change the logical architecture described in this document; Advantco OpenPGP continues to operate strictly as a cryptographic service and does not perform message routing or transport.

9. Conclusion

This reference architecture defines a clear separation between cryptographic services, message transport, and business logic for secure SAP–AI integration. By exposing OpenPGP operations as governed APIs and keeping data transport outside the cryptographic service boundary, the architecture enables strong security guarantees while remaining flexible, deployment-neutral, and suitable for enterprise use.

10. Sources

https://www.sap.com/products/technology-platform.html
https://www.rfc-editor.org/rfc/rfc4880
https://owasp.org/www-project-api-security/
https://www.advantco.com/sap-integration-adapters/sap-pgp-integration

Configure Role Owner Stage Auto Approval in SAP IAG

2026-01-23T06:15:25.857000+01:00

Introduction

This blog explains how to configure Role Owner Stage Auto Approval in IAG. focusing on setting up the required data objects, business rules, and workflow configuration to automate approvals.

Step 1: Create Data Object

Create a data object called RoleOwnerAttributes. This object holds the input values used to determine whether the Role Owner stage should be automatically approved.

Add the following attributes to the data object:

roleName (String)
roleCriticality (String)
roleApprover (String)
roleBusinessProcess (String)
roleSubprocess (String)
roleRiskCount (Number)

Step 2: Create another Data Object

Create another data object called AutoApproveRoleOwnerStage. This object stores the output of the rule.

Add the following attributes to the data object:

roleName (String)
roleOwnerAutoStage (Boolean)

Step 3: Create Local Rule
Create a local rule called RoleOwnerStageAutoRule

decision table settings:

Use the fields from RoleOwnerAttributes (Step 1) as the conditions.
Use AutoApproveRoleOwnerStage (Step 2) as the result.

Result Attributes:

Role Owner Auto Stage → Access: Editable
Role Name → Access: Hidden
Set the hardcoded value as the roleName from RoleOwnerAttributes.

In this scenario, the condition is defined based on the Role Name.

Step 4: Create Rule Set

Create a rule set called RoleOwnerRuleSet and add the local rule RoleOwnerStageAutoRule (from Step 3) to it.

Step 5: Create Rule Service

Create a rule service called AutoApproveRoleOwnerStage.

Input → RoleOwnerAttributes (from Step 1)
Result → AutoApproveRoleOwnerStage (from Step 2)

Step 6: Assign Rule Service

Assign the rule service AutoApproveRoleOwnerStage (from Step 5) to the rule set RoleOwnerRuleSet (from Step 4).

Step 7: Activate and Deploy

Activate all the created objects and deploy the business rule service. If any changes are made, the service must be deployed again.

Existing Workflow Setup

In the current existing workflow, the access request is configured to follow the Role Owner approval path as the stage 1 during the approval process.

Testing Scenario

The following test scenario was performed to validate the configuration:

An access request was raised for the role PR_approver_0_1M.
The audit log shows that the request was automatically approved by the system.
The Access request status shows that it moved to the Risk Owner stage, confirming that the Role Owner stage was automatically approved successfully.

Conclusion

Role Owner stage auto approval reduces manual effort and speeds up the approval process for eligible access requests. Using rule-based conditions, organizations can automatically approve condition based requests while keeping manual approvals for critical cases.

Runtime Threat Detection for SAP BTP Kyma with Azure Arc + Microsoft Defender for Containers

2026-02-02T15:52:32.766000+01:00

Securing an external Kubernetes cluster with Microsoft Defender for Containers (via Azure Arc)

When I say "secure Kubernetes", I'm not just thinking about admission policies and CIS checklists. I'm thinking about what happens when something is already running and turns malicious — a web shell lands in a pod, a container starts burning CPU for crypto mining, or someone drops network scanning tools into an otherwise boring workload.

If you're running SAP BTP Kyma runtime, this matters. Kyma has strong platform hardening (Gardener-managed control plane, DISA STIG alignment), and API server audit logs exist — but those logs go to SAP's Platform Logging Service, not directly to you. That's fine for platform-level auditing, but it's not the same as seeing threats inside your workloads at runtime.

That's the gap I'm filling: runtime threat detection — the ability to detect and alert on malicious activity (crypto mining, web shells, credential theft) while workloads are running.

Real-world threats

These aren't hypotheticals — crypto mining and container compromise campaigns are actively targeting Kubernetes clusters:

DERO Cryptojacking (2023–2024): Attackers scanned for misconfigured Kubernetes API servers, then deployed DaemonSets named "proxy-api" to blend in with legitimate cluster components. The mining process itself was named "pause" — masquerading as the standard Kubernetes pause container. CrowdStrike found malicious images with over 10,000 pulls on Docker Hub. How runtime detection helps: Defender's eBPF monitoring catches unusual process spawning from "pause" containers and flags sustained high CPU from processes that shouldn't be compute-intensive. (Source: CrowdStrike — DERO Cryptojacking Discovery)

Kinsing Campaign (2023–ongoing): This campaign exploits vulnerabilities in PostgreSQL, WebLogic, Liferay, and WordPress to gain initial access to containers, then pivots to deploy crypto miners across the cluster. The campaign has affected 75+ cloud-native applications. How runtime detection helps: Defender detects process genealogy anomalies — for example, a WebLogic process spawning shell commands that enumerate Kubernetes resources or deploy new containers.

The pattern: attackers get in through a misconfiguration or vulnerability, then run workloads inside the cluster. Admission policies and CIS benchmarks don't catch threats that start after deployment — that's the gap runtime detection fills.

The solution: Azure Arc + Defender for Containers

For non-AKS clusters, the approach is: Azure Arc (makes the cluster an Azure resource) + Defender for Containers (deploys the runtime sensor as an Arc extension).

What gets installed:

Arc agents (azure-arc namespace): maintain outbound connection to Azure
Defender sensor (DaemonSet on each node): collects runtime telemetry via eBPF — process creation, network activity, system calls

What the sensor detects: crypto mining patterns, web shell activity, network scanning tools, binary drift. (Docs: Workload runtime detection)

Arc also provides an extension platform — Defender isn't the only add-on you can deploy this way. And Microsoft provides a verification checklist so you can prove it's working.

Networking note: Both Arc and Defender require outbound connectivity. If egress is blocked, onboarding fails silently. Check the Arc network requirements and ensure *.cloud.defender.microsoft.com:443 is allowed.

How

I’ll show a portal-first path (fastest to understand), then a programmatic path (fastest to automate).

Step 0 — Pre-flight checklist

Here’s what I personally confirm before I touch the portal:

1) Network egress (outbound)

Arc agents require outbound access to a set of URLs (Azure Resource Manager, Entra ID token endpoints, container registries for pulling agent images, and more depending on features). (Docs: Azure Arc-enabled Kubernetes network requirements)
Defender for Containers on Arc requires outbound access to *.cloud.defender.microsoft.com:443. (Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

2) Tooling

Azure CLI + the connectedk8s extension (for Arc onboarding). (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)
If I want to script extension deployment, I also install the k8s-extension extension. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

3) Cluster access

kubectl works and points at the cluster I’m onboarding.
If I’m missing kubeconfig on my workstation, the Kyma Dashboard has a Download kubeconfig link for the cluster.
I sanity-check that my kubeconfig/current context is the Kyma cluster before running anything destructive:

kubectl config current-context
kubectl cluster-info

I have capacity for Arc agents (the Arc quickstart calls out resource requirements and that agents are deployed on connect). (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

Step 1 — Connect the cluster to Azure Arc

I typically do this from a workstation that already has kubectl access to the cluster.

1.1 Register providers (if needed)

The Arc quickstart includes registering resource providers like Microsoft.Kubernetes, Microsoft.KubernetesConfiguration, and Microsoft.ExtendedLocation. (Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

1.2 Run the connect command

From the Arc quickstart, the core command is:

az connectedk8s connect --name <cluster-name> --resource-group <resource-group>

In practice, I prefer to be explicit (especially on shared subscriptions) and set --location and --tags:

az connectedk8s connect \
    --name <cluster-name> \
    --resource-group <resource-group> \
    --location <azure-region> \
    --tags env=<env> owner=<team> system=<system>

What I’m explicitly setting there:

--location: the Azure region where the Azure Arc-enabled Kubernetes resource is created. If you omit it, it’s created in the same region as the resource group.
--tags: Azure Resource Manager tags on the Arc resource (space-separated key[=value]).

If this command hangs or fails in weird ways, I go back to egress first — the Arc network requirements doc is the authoritative “what URLs/ports must my cluster reach?” list. (Docs: Azure Arc-enabled Kubernetes network requirements)

(Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc and Azure CLI reference — az connectedk8s connect)

1.3 Verify Arc agents in the cluster

The quickstart calls out that Arc deploys agents into the azure-arc namespace. I validate that they’re Running:

kubectl get deployments,pods -n azure-arc

(Docs: Quickstart: Connect an existing Kubernetes cluster to Azure Arc)

Here’s what that looks like in practice on my Kyma cluster:

And here’s the connected cluster resource in Azure (showing things like connectivity status, location, and tags):

At this point, if Arc isn’t healthy, I stop and fix that first. Everything else depends on it.

Step 2 — Enable the Containers plan in Microsoft Defender for Cloud

Now I go to Defender for Cloud and enable the Containers plan for the subscription where my Arc-enabled cluster lives.

The portal walkthrough is:

Microsoft Defender for Cloud → Environment settings → pick subscription → toggle Containers plan On
Select Settings next to the Containers plan → choose Enable specific components

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

At this point you’ll be asked which Containers plan components to enable.

You can enable everything, but for this post I’m intentionally focusing on the Defender sensor (runtime detections). The important callout: from a pricing perspective there’s no cost benefit to enabling one vs. many — the cost is the same — so this is purely about keeping the walkthrough scoped to runtime detection.

Here’s what that looks like in the portal (first the Containers plan settings, then the component selection where I keep only the sensor in scope):

Step 3 — Deploy Defender components to the Arc-enabled cluster

I use one of two flows.

Option A (recommended): Deploy via Defender for Cloud Recommendations

This is the “guided remediation” path:

Defender for Cloud → Recommendations
Find “Azure Arc-enabled Kubernetes clusters should have Defender extension installed”
Select the clusters → Fix

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

Option B: Deploy manually from the Arc cluster resource

If I want explicit control (or I’m debugging), I do:

Arc-enabled Kubernetes resource → Extensions → + Add
Install Microsoft Defender for Containers
Choose/configure the Log Analytics workspace during installation (this is where the extension sends collected logs/telemetry used by Defender for Cloud and Azure Monitor Logs)
- I can select an existing workspace, create a new one, or use the default: DefaultWorkspace-[subscription-id]-[region]

(Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

Step 4 (optional) — Programmatic deployment (repeatable automation)

If I’m onboarding clusters at scale, I don’t want a click path. The programmatic doc gives the Azure CLI commands for creating the Defender extension.

Defender sensor extension:

Note: Some examples include an auditLogPath setting for clusters where you control the API server audit log file location. In Kyma, audit logs are handled via SAP’s Platform Logging Service and you generally don’t have direct access to that file path, so I’m omitting it here.

az k8s-extension create \
    --name microsoft.azuredefender.kubernetes \    --cluster-type connectedClusters \    --cluster-name <cluster-name> \    --resource-group <resource-group> \    --extension-type microsoft.azuredefender.kubernetes \    --configuration-settings \        logAnalyticsWorkspaceResourceID="/subscriptions/<subscription-id>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"

(Docs: Deploy Defender for Containers on Arc-enabled Kubernetes (programmatic))

If you need the generic “how do extensions work / how do I list/update/delete them” reference, the Arc extensions doc is the canonical place. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

Step 5 — Verify it’s actually working

This is where I slow down and prove success.

Microsoft’s verification checklist is:

Arc connection is healthy
Defender extension shows as installed
Sensor pods are running
Alerts appearing

(Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.1 Verify Arc connectivity

az connectedk8s show \
    --name <cluster-name> \    --resource-group <resource-group> \    --query connectivityStatus

The expected output is Connected. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.2 Verify Defender extension provisioning

az k8s-extension show \
    --name microsoft.azuredefender.kubernetes \    --cluster-type connectedClusters \    --cluster-name <cluster-name> \    --resource-group <resource-group> \    --query provisioningState

The expected output is Succeeded. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.3 Verify sensor pods

kubectl get pods -n kube-system -l app=microsoft-defender

# If you don’t see anything in kube-system, also check the mdc namespace:
kubectl get ds -n mdc
kubectl get pods -n mdc

This is the simplest “is the sensor deployed?” check. If the DaemonSet exists and the pods are Running, you’re in good shape.

(Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.4 Verify in the portal

This is the “did Azure actually receive the signals?” check.

After you’ve deployed the Defender extension and the sensor is running, go to Microsoft Defender for Cloud and look at Security alerts (or the Alerts view in the Defender for Cloud experience). If you just ran the simulator (next step), this is where you’ll see the resulting alerts.

It can take a bit of time (think minutes, not seconds) for the cluster and alerts to show up after onboarding. (Docs: Verify Defender for Containers on Arc-enabled Kubernetes)

5.5 (Optional) Prove runtime detection by simulating alerts

If I want hard proof that the sensor-backed detections are flowing end-to-end, I use Microsoft’s Kubernetes alerts simulation tool.

It has two prerequisites that matter in practice:

Defender for Containers is enabled and the Defender sensor is deployed.
I have admin permissions on the cluster.

Then I download and run the simulator:

curl -O https://raw.githubusercontent.com/microsoft/Defender-for-Cloud-Attack-Simulation/refs/heads/main/simulation.py
python simulation.py

After it runs, I go back to Defender for Cloud and look at the alerts that were generated:

(Docs: Kubernetes alerts — Kubernetes alerts simulation tool)

5.6 Inspect the alert details (example: binary drift)

To make this feel real (and to sanity-check what Defender is actually flagging), I open one of the generated alerts and look at the Alert details pane. For example, the “A drift binary detected executing in the container” alert includes fields like the suspicious process path, command line, parent process, and the affected Arc-enabled Kubernetes resource.

Step 6 — Troubleshooting (the short list)

6.1 If an extension is stuck, check egress first

Arc-required outbound URLs: (Docs: Azure Arc-enabled Kubernetes network requirements)
Defender-required outbound endpoint (*.cloud.defender.microsoft.com:443) (Docs: Enable Defender for Containers on Arc-enabled Kubernetes (portal))

6.2 If things drift over time

The Arc extensions doc notes that if Arc agents don’t have network connectivity for an extended period, an extension can transition to Failed, and you may need to recreate the extension. (Docs: Deploy and manage Arc-enabled Kubernetes extensions)

Closing thoughts

If you’re running Kubernetes outside AKS, it’s easy to end up with fragmented security tooling. The Arc + Defender for Containers pattern is one of the cleaner ways I’ve found to bring:

centralized visibility,
actionable runtime alerts,
and runtime security signals

into a hybrid Kubernetes estate—without replatforming.

In future posts, I’ll explore what else we can do with Kyma + Azure Arc + Azure beyond Defender for Containers (observability, more security patterns, etc.).

References (Microsoft Learn)

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

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!

UI for the BTP Application Vulnerability Report

2026-02-10T22:42:33.106000+01:00

SAP recently introduced the Application Vulnerability Report for Cloud Foundry applications on BTP. It is a tool that scans your deployed applications for known vulnerabilities and exposes the findings through an API. If you haven't seen it yet, check out the official announcement: https://community.sap.com/t5/technology-blog-posts-by-sap/introducing-application-vulnerability-report-for-cloudfoundry-applications/ba-p/14281684

The API is great, but what was missing is an interface to browse, search, filter, sort and export those findings. So I built one. In this blog post I'll walk you through the open-source UI I created on top of the BTP Application Vulnerability Report API.

Problem

The Application Vulnerability Report API provides: vulnerability descriptions, severity levels, affected packages, CVE identifiers and the full organizational context (global account, sub-account, space, org). However, consuming a raw API to get an overview of your security posture is not practical for most teams. You need to be able to:

Quickly scan through all findings at a glance
Sort by severity, application name or date to prioritize remediation
Filter by sub-account, space, organization or any other column
Search across all findings with a free-text search
Export the full report to Excel for offline analysis or sharing with stakeholders

Solution

That's what I tried to solve by adding this UI: a full SAPUI5 frontend backed by a CAP Node.js service that proxies the BTP API, deployed via the managed approuter on BTP. The CAP layer might be a bit overkill at this point but it offers flexibility for future improvements.

The first version comes with the following features:

Sorting: Click column headers to sort findings
Filtering: Right-click cells or use column menus to filter by severity, application, sub-account, space or any field
Free-Text Search: Search across all finding properties using CVE numbers, package names or application names
Export to Excel: Generate formatted .xlsx files with all 15 fields including recommendations, dates, finding IDs and CVSS scores
Severity Indicators: Color-coded findings (Critical/High in red, Moderate in orange, Low in blue) for instant visual prioritization

Architecture Overview

The project consists of two parts:

CAP Node.js Backend: A lightweight OData V4 service that acts as a proxy to the BTP Application Vulnerability Report API. It connects to the external API via a BTP Destination with OAuth2 authentication. The CAP service defines the Findings entity as a projection on the external service model and uses api.run(req.query) to forward OData queries. At this point, the only value of having CAP is for merging some array fields into one single column:

SAPUI5 Frontend: A freestyle UI5 application with a table to show the overview and provide some additional functionalities like sorting, filtering and an export to excel. Now thinking about it, this could’ve been a Fiori Elements app as well. The app is deployed to the HTML5 Application Repository and served via the managed approuter of SAP Build Work Zone.

Getting It Up and Running

Prerequisites

Node.js >= 18
SAP CAP CLI (npm i -g @sap/cds-dk)
Cloud MTA Build Tool (npm i -g mbt)
CF CLI with the MTA plugin
A BTP subaccount with the Application Vulnerability Report service enabled

Step 1: Clone the Repository

git clone https://github.com/lemaiwo/btp-application-vulnerability-report-ui.git
cd btp-application-vulnerability-report-ui
npm install

Step 2: Create the BTP Destination

In your BTP subaccount, create a destination named "BTPVulnerabilityReport" that points to the Application Vulnerability Report API. Configure it with OAuth2ClientCredentials authentication using the credentials from your service key.

Step 3: Build and Deploy

mbt build -t gen --mtar btpvulnerabilityreport.mtar
cf deploy gen/btpvulnerabilityreport.mtar

The MTA deployment creates:

A CAP Node.js backend application
An XSUAA service instance for authentication
A Destination service instance (with HTML5 runtime enabled)
An HTML5 Application Repository entry for the UI5 app

Step 4: Access the App

The application is deployed using the managed approuter pattern. You can access it through SAP Build Work Zone by adding it as an application tile. The Fiori Launchpad integration is pre-configured with the semantic object "VulnerabilityReport" and action "display".

Local Development

For local development, run cds watch from the project root (not ui5 serve from the app folder). The cds-plugin-ui5 plugin serves the UI5 app directly from the CAP server. To test against the real BTP API locally, use the hybrid profile: cds watch --profile hybrid after binding the destination service with cds bind.

No Database Required

The application does not use a database. All data comes directly from the BTP API in real-time. This keeps the architecture simple and ensures you always see the latest findings without any synchronization concerns.

What's Next?

The current version uses the managed approuter of SAP Build Work Zone for serving the application. I'm considering adding a standalone approuter configuration as an alternative for scenarios where Work Zone is not available or needed.

Other ideas for future enhancements include dashboard charts for severity distribution, drill-down to individual finding details and scheduled notifications for new critical findings.

Contributions and feedback are welcome! The full source code is available on GitHub:

https://github.com/lemaiwo/btp-application-vulnerability-report-ui

References

Introducing Application Vulnerability Report for CloudFoundry Applications (SAP Community Blog): https://community.sap.com/t5/technology-blog-posts-by-sap/introducing-application-vulnerability-report-for-cloudfoundry-applications/ba-p/14281684
GitHub Repository: https://github.com/lemaiwo/btp-application-vulnerability-report-ui

The Hidden Threat to Your Clean Core: Variant Governance in S/4HANA

2026-02-11T21:50:33.739000+01:00

By Atul Joshi — Lead SAP Architect, Utilities & Clean Core Specialist

Introduction

Organizations invest millions in S/4HANA transformations, aiming for a Clean Core, agile upgrades, and a future‑proof digital landscape. We move custom code to BTP, rationalize interfaces, and modernize processes.

Yet one silent, often overlooked threat can undermine all of that work: uncontrolled variant changes in production batch jobs.

A single unauthorized variant change can cause incorrect billing, incomplete financial postings, or regulatory reporting issues. These failures are not technical—they are governance failures. And they can compromise Clean Core integrity even when no Z‑code exists.

Why Variant Governance Fails in Utilities and S/4HANA Landscapes

1. “Temporary Fix” Syndrome

A user changes a variant “just for today” and forgets to revert it.

2. Lack of Awareness

Users do not understand the downstream impact of altering a production variant.

3. Over‑Authorization

Security roles grant variant maintenance access where only execution is required.

The result is a silent failure that may not surface until weeks later—after financial cycles close, billing runs complete, or regulatory reports are submitted.

A Real‑World Case: The Variant That Broke a Month of Processing

A nightly batch report was scheduled using Variant X, configured to process all company codes. It ran successfully for months.

One day, a well‑meaning user modified Variant X and restricted it to a single company code, assuming it was a temporary adjustment.

No one noticed.

For the next month, the batch job processed only that one company code. No dumps, no warnings, no alerts. The issue surfaced only during reconciliation, when the business noticed missing postings across multiple entities.

By then:

Downstream reports were incorrect
Financial data was incomplete
Audit trails were inconsistent
Cleanup required days of effort

This was not a technical issue. It was a governance failure—and a perfect example of how a single variant change can undermine Clean Core stability.

Why This Threatens Clean Core

Clean Core is not only about removing custom code. It is about predictability, stability, and governance.

A single variant change can:

Break standardized processes
Trigger incorrect financial or billing results
Create audit and compliance risks
Force emergency patches
Introduce new technical debt

You can have zero Z‑code and still have a “dirty core” if your variants are uncontrolled.

My Approach to Variant Hardening

To address this risk, I use a three‑layer governance model that protects mission‑critical batch processes. This approach combines technical controls with operational discipline.

Layer 1: Protect Variant Flag — First Line of Defense

Every production variant should have the Protect Variant flag enabled (SE38 or program RSVARATT).

How it works:

Only the creator or last protector can modify the variant. Others can execute it, but fields become read‑only.

Benefit:

Prevents casual or accidental modifications.

Limitation:

It is a single point of failure—additional layers are required.

Layer 2: SAP Security Authorization — Granular Access Control

This is the enterprise‑grade safeguard.

Key object: S_PROGRAM

Key field: P_ACTION

Best practice:

Business users → SUBMIT only
Variant maintenance (VARIANT) → restricted to a small governance group

Impact:

Even if someone attempts to unprotect a variant, they cannot save changes without the correct authorization.

Layer 3: ABAP Validation — The Final Safety Net

For critical programs, embed validation logic inside the ABAP code.

Example:

abap

AT SELECTION-SCREEN.

IF sy-batch = 'X'.

IF s_company_code IS INITIAL.

MESSAGE 'Company Code is mandatory for batch execution. Job aborted.' TYPE 'A'.

ENDIF.

IF p_date_from > p_date_to.

MESSAGE 'Invalid date range. Job aborted.' TYPE 'A'.

ENDIF.

Result:

Even if a variant bypasses the first two layers, the program aborts before processing incorrect data.

The Executive Mandate: Variant Governance as a Clean Core Requirement

Variant governance must be elevated from a technical detail to a strategic governance priority.

As architects, we must:

Educate business teams
Enforce governance protocols
Treat variant control as part of Clean Core
Elevate this topic to leadership

The cost of prevention is minimal compared to the cost of correction.

By implementing this 3‑layer protocol, organizations can:

Protect data integrity
Ensure compliance
Improve operational stability
Safeguard their Clean Core investment

This is not just configuration—it is operational excellence.

Let’s Discuss

What challenges do you face in managing variants in your SAP landscape? Have you experienced a variant‑related incident?

Share your experiences below—let’s architect better governance together.

SAP BTP XSUAA Security Configuration Comparison: Attribute-Based vs. Authority-Based Approaches

2026-02-18T03:27:30.148000+01:00

In SAP Business Technology Platform (BTP) Cloud Foundry applications, configuring XSUAA (Extended Services for User Account and Authentication) via the xs-security.json file is a critical step for secure authentication and authorization.

Sample Application used for this article - "Message Reprocessing Application". This scenario try to cover 2 roles - "ReprocessViewer" and "ReprocessAdministrator".

Two main approaches exist:

Configuration A: Explicit attribute-based – manual mapping and control
Configuration B: Authority-based – automatic acceptance of IDP attributes (recommended for most cases)

Understanding the differences helps you balance security, compliance, simplicity, and development speed.

Quick Comparison Table

Feature                          | Config A (Explicit Attributes)          | Config B (Authority-Based)
---------------------------------|-----------------------------------------|--------------------------------------------
attributes section               | ✅ Present (defines email, etc.)        | ❌ Not needed
attribute-references in roles    | ✅ Yes (links attributes to roles)      | ❌ Not present
authorities array                | ❌ Not used                              | ✅ "$ACCEPT_GRANTED_AUTHORITIES"
oauth2 grant-types               | ❌ Uses defaults                         | ✅ Explicit list (authorization_code + others)
oauth2 autoapprove               | ❌ Not set (shows consent screen)       | ✅ true (smooth internal login)

Key takeaway from the table

Configuration A: Explicit Attribute-Based Approach

Structure (xs-security.json excerpt):

JSON

{
  "xsappname": "my-app-reprocess-v2",
  "tenant-mode": "dedicated",
  "description": "Message Reprocessing Application - Security Configuration",
  "scopes": [
    {
      "name": "$XSAPPNAME.ReprocessViewer",
      "description": "View messages, content, and statistics (read-only access)"
    },
    {
      "name": "$XSAPPNAME.ReprocessAdministrator",
      "description": "Full administrative access including reprocess operations and CRUD"
    }
  ],
  "attributes": [
    {
      "name": "email",
      "description": "User email address",
      "valueType": "string"
    }
  ],
  "role-templates": [
    {
      "name": "ReprocessViewer",
      "description": "Read-Only Access - View messages and statistics",
      "scope-references": ["$XSAPPNAME.ReprocessViewer"],
      "attribute-references": ["email"]
    },
    {
      "name": "ReprocessAdministrator",
      "description": "Full Administrative Access - CRUD operations and reprocess actions",
      "scope-references": [
        "$XSAPPNAME.ReprocessAdministrator",
        "$XSAPPNAME.ReprocessViewer"
      ],
      "attribute-references": ["email"]
    }
  ],
  "role-collections": [
    {
      "name": "MessageReprocessViewersRC",
      "description": "Message Reprocess Viewers - Read-only access",
      "role-template-references": ["$XSAPPNAME.ReprocessViewer"]
    },
    {
      "name": "MessageReprocessAdministratorsRC",
      "description": "Message Reprocess Administrators - Full access",
      "role-template-references": ["$XSAPPNAME.ReprocessAdministrator"]
    }
  ],
  "oauth2-configuration": {
    "credential-types": ["binding-secret", "x509"],
    "redirect-uris": ["https://*.cfapps.example.com/**", "http://localhost:*/**"],
    "token-validity": 3600,
    "refresh-token-validity": 86400
  }
}

Advantages

Explicit control over exposed attributes
Fine-grained security and compliance
Enables attribute transformation and ABAC

Disadvantages

Higher maintenance
More complex configuration
Less flexible with IDP changes

When to use: Regulated industries (healthcare, finance, government), ABAC needs, multi-tenant SaaS, strict governance.

Configuration B: Authority-Based Approach (Recommended)

Structure (xs-security.json excerpt):

JSON

{
  "xsappname": "my-app-reprocess-v2",
  "tenant-mode": "dedicated",
  "description": "Message Reprocessing Application - Security Configuration",
  "scopes": [ /* same as above */ ],
  "role-templates": [ /* same as above, without attribute-references */ ],
  "role-collections": [ /* same as above */ ],
  "authorities": ["$ACCEPT_GRANTED_AUTHORITIES"],
  "oauth2-configuration": {
    "grant-types": ["authorization_code", "client_credentials", "refresh_token"],
    "credential-types": ["binding-secret", "x509"],
    "redirect-uris": ["https://*.cfapps.example.com/**", "http://localhost:*/**"],
    "token-validity": 3600,
    "refresh-token-validity": 86400,
    "autoapprove": true
  }
}

Advantages

Simplicity and minimal config
Automatic handling of standard IDP attributes
Lower maintenance, faster development
Seamless with SAP IAS, Azure AD, Okta

Disadvantages

Less granular control (all attributes passed)
Potential over-exposure

When to use (most cases): Standard enterprise apps, RBAC, rapid development, microservices, agile environments.

Deep Dive: Key Differences

Attributes & attribute-references — Explicit in A, automatic in B via $ACCEPT_GRANTED_AUTHORITIES
Authorities — Special directive in B accepts all granted attributes/scopes from trusted IDP
OAuth grant-types & autoapprove — Explicit in B for predictability and better UX (no consent screen for internal apps)

JWT Token Examples

Configuration A (Explicit):

JSON

{
  "user_name": "john.doe",
  "email": "john.doe@example.com",
  "scope": ["my-app-reprocess-v2.ReprocessViewer"],
  "xs.user.attributes": { "email": ["john.doe@example.com"] }
}

Configuration B (Automatic):

JSON

{
  "user_name": "john.doe",
  "email": "john.doe@example.com",
  "given_name": "John",
  "family_name": "Doe",
  "scope": ["my-app-reprocess-v2.ReprocessViewer"],
  "xs.user.attributes": { "email": ["john.doe@example.com"], "department": ["Engineering"], "cost_center": ["CC-1234"] }
}

Application Code Impact (Examples)

SAP CAP (Node.js) – Configuration B:

JavaScript

this.before('READ', 'Messages', async (req) => {
  const userEmail = req.user.attr.email;
  const department = req.user.attr.department;  // extra attributes available
  // ...
});

Spring Boot (Java) – Configuration B:

Java

String email = token.getAttributeFromClaimAsString("email");
String department = token.getAttributeFromClaimAsString("department");

Migration Guide & Troubleshooting

(Refer to the detailed steps in original content for From A → B and vice versa, plus common issues like missing attributes, invalid grant types, consent screens, token size.)

Security & Performance Best Practices

Principle of least privilege
Validate JWT properly (@sap/xssec)
Specific redirect URIs (avoid wildcards in prod)
Appropriate token lifetimes
Prefer X.509 in production
Monitor token size (switch to A if >4KB)

Recommendations by Use Case

Use CaseRecommendedRationaleInternal Enterprise AppConfiguration BSimplicity & standard integrationRegulated IndustryConfiguration AExplicit governance & audit trailRapid Prototype/MVPConfiguration BMinimal configAttribute-Based AuthorizationConfiguration ARequired for ABAC

Conclusion For most SAP BTP applications in 2025, go with Configuration B (Authority-Based) — it delivers simplicity, flexibility, and aligns with modern OAuth/OIDC patterns while reducing maintenance.

Only choose Configuration A when you need strict attribute control, custom transformations, or operate in highly regulated environments.

What approach are you using in your SAP BTP projects? Have you migrated between the two? Share your experiences or questions in the comments — happy to discuss architecture or troubleshooting!

#SAPBTP #XSUAA #CloudFoundry #SAPSecurity #Authorization #IdentityManagement #SAPDeveloper

When Business Asks for a Bicycle, Don't Build a Spaceship

2026-02-21T19:02:14.003000+01:00

When Business Asks for a Bicycle, Don't Build a Spaceship

I have developed a comprehensive playbook demonstrating how modern SAP tools and AI can deliver solutions in DAYS instead of MONTHS.

The shocking math:
- Traditional approach: 6 months, $650K in delayed value
- SAP tools + AI: 1 week, $25K in delayed value

This isn't just theory—it's a practical guide that covers:
- CDS Views for data modeling
- CAP for service generation
- Fiori Elements for instant UIs
- Integration Suite for connectivity
- AI to accelerate everything

https://www.linkedin.com/posts/rajesh-putumbaka-456267101_sap-btp-ai-development-playbook-ugcPost-7431029390173696001-y7Yn?utm_source=share&utm_medium=member_desktop&rcm=ACoAABnYP8IBvlY4GDRmR8utVFLHXZ61gUvSa-0
Download the full playbook (PDF attached) and share your thoughts: Have you encountered the "perfect is the enemy of good" trap in your SAP projects?
#SAP #DigitalTransformation #AI #SAPCommunity

SAP Community - SAP BTP Security

How to Integrate SAP BTP Cloud Logging Service with SAP Cloud Identity Services (IAS) Using SAML

Introduction

Step 1: Prepare IAS for SAML Integration

Step 2: Create IAS Group for Admin Access

Step 3: Generate Signing Key and Certificate (Optional)

Step 4: Configure Cloud Logging Service

Step 5: Validate the Integration

Troubleshooting

Conclusion

SAP TechEd 2025 Virtual: Experience the best of SAP TechEd and broaden your SAP security expertise

How to secure your integration flows in SAP Integration Suite

Project Foxhound - on the Scent of Client-Side Web Vulnerabilities

Background

Project Foxhound

Features

History

Why Foxhound?!

Find out More

Accessing BTP User Security Using APIs of the SAP Authorization and Trust Management Service

Introduction

Pre-requisite

Create a credential for API access

Call the API

Conclusion

Introducing Application Vulnerability Report for Cloudfoundry Applications – Try It Now!

What Is Application Vulnerability Report?

How to enable in your tenant ?

Service Marketplace

Create Instance in your Cloud Foundry space

Create Service Key

Allow the User to Access the Space

Why Is This Important?

Application Vulnerability Report - Process overview

Overview of the each Process flow

1. Applications Running on SAP BTP

2. Scanning Layer

3. Application Vulnerability Report for SAP BTP

4. API for Customers

5. Customers

Technical UsageHow to get findings of your deployed CF applications running.

Reference:

External resource:

Securing CAP Applications with SAP Cloud Identity Services and AMS

Introduction

Authorization Management Service(AMS) and CAP

Use AMS as Authorization Management System on SAP BTP

CDS-Based Authorization

Solution Diagram

Integrate With the Authorization Management Service into CAP Application

Configure AMS Integration in CAP Application

Configure Users for Local Testing

Wrap-Up

Beta Version of Application Vulnerability Report for SAP BTP Now Available

What is this new service all about?

What does the new application vulnerability report service offer you?

Get started now!

Automating User Offboarding in SAP BTP Across Multiple Subaccounts with PowerShell & BTP CLI

How to Export All Users (with Origins) from All SAP BTP Subaccounts via CLI Automation

New Expert-Guided Implementation: Joule Prerequisites and Activation

Establish the Foundation for Your AI Journey

Workshop Schedule

Why This EGI Matters

What You’ll Learn: Program Overview

What You Will Achieve

How to Register

Related Articles

Secure SAP–AI Integration Using Advantco OpenPGP Services

Configure Role Owner Stage Auto Approval in SAP IAG

Runtime Threat Detection for SAP BTP Kyma with Azure Arc + Microsoft Defender for Containers

Securing an external Kubernetes cluster with Microsoft Defender for Containers (via Azure Arc)

Real-world threats

The solution: Azure Arc + Defender for Containers

How

Step 0 — Pre-flight checklist

Step 1 — Connect the cluster to Azure Arc

1.1 Register providers (if needed)

1.2 Run the connect command

1.3 Verify Arc agents in the cluster

Step 2 — Enable the Containers plan in Microsoft Defender for Cloud

Technical Usage

How to get findings of your deployed CF applications running.