SAP Community - Martin Pankraz

Nice patch SAP! Revisiting your SAP BTP security measures after AI Core vulnerability fix

2024-07-25T10:46:43.272000+02:00

Dear community,

SAP recently fixed a critical vulnerability in the SAP AI Core service that could have allowed attackers to access sensitive data in the multi-tenant environment. This issue, dubbed "SAPwned", was responsibly disclosed and publicly shared on July 18 after it was patched. You can read more about it here.

Bottom line: SAP shows its commitment to security and timely patching of its cloud services. But remember, SAP BTP - like any cloud platform - is based on a shared responsibility model. That means you need to do your part to protect your data and applications too:

Pick secure authentication means (no Basic AUTH is not one of them!),
Be conscious that every endpoint exposed by SAP BTP like Microsoft365 lives on the Internet by design,
Scope Cloud Foundry + Kyma app access, and user roles to the minimum rights needed,
When using the popular” OAuth2 client credentials grant” with service keys rotate your secrets (at best automatically regularly)! Have your pick from app based solution like this, PowerShell module and blog on automatic cert renewal.
Establish a continuous process to harden your SAP cloud workloads. It is not a one stop shop.

Ever heard about “MFA fatigue”? Plain Multi-Factor-Authentication is not good enough anymore today. Additionally, enforce Conditional Access to SAP BTP service through integration the SAP ID Service or the SAP Identity Authentication Service with the corporate identity provider of your choice. See here how to do it with Microsoft Entra ID.

Second line of defense: Automatic detections based on the SAP Audit Log Service

Most of the BTP based services in the Cloud Foundry environment provided by SAP automatically write to the SAP Audit Log Service. Each service lists the standardized events that are propagated.

SAP has a nice video on the general workings of the SAP Audit Log Service on BTP.

This is a good start, but how useful are log entries that record a compromise if they are overlooked and hidden among countless normal entries?

I use the Microsoft Sentinel for SAP BTP solution - which went into General Availability state this week - as an example for running automatic detections via built-in analytic rules. It connects to your subaccounts and global account ingesting all audit logs that are written to your registered Audit Log Management service instances. Polling interval is 10mins when deployed from the Azure Portal by default. Configure down to 1 min if needed using ARM API.

Architecture diagram of Sentinel solution for SAP BTP

It comes with out-of-the-box content. Check out the alert “Failed access attempts across multiple Business Application Studio accounts” for instance. Password spray attack anyone?

Screenshot of Sentinel for SAP BTP solution content with out-of-the-box detections and workbooks

Once I have onboarded my subaccount (I named it SAP-AI-Core-playground), I can go wild on the ingested log entries, apply the threat intel functions, and built analytic rules. Let's browse the entries via the Kusto query language. The standard table SAPBTPAuditLog_CL holds all audit log info for your registered SAP BTP subaccounts:

Screenshot of simple KQL for SAP BTP

The Message contains the JSON payload BTP provides for each message as well as the involved BTP service identifier.

Looking at audit messages is nice, but you may go one step further by applying automatic action like blocking the SAP BTP users.

Below Screenshot shows the part of the process triggered by the included playbook. The SAP security team gets notified with evidence of the compromise, offering an approval option to block the user from a Microsoft Teams channel flow. Find more info here. Below screenshot shows the adaptive card with a trigger from SAP Business Suite. The same is possible with triggers coming from BTP too.

Screenshot of sap btp user block approval request to SAP security team on Microsoft Teams

The AI Core Service audit log entries alone are not useful

Threat protection-wise correlation with other signals in your company is required, because a single SAP AI Core event like “Successful retrieval of object store secret” does not tell you anything. See below a Kusto query working off the AI Core audit log info ingested by the Sentinel for SAP BTP solution.

Note: SAP publishes the available events for all the Cloud Foundry based services here.

It identifies entries on my BTP subaccount related to AI Core activity and cross-references the IP address involved in the login and its country of origin. In my sample below I use the built-in function geo_info_from_ip_address() to learn if the BTP client remote address originated from Germany or not. Assumption here is that all my BTP developers are based there. Think about sanctioned countries lists etc.

//flag unexpected logins from countries other than Germany
let myBTPDevelopers = dynamic(['Germany']);
let login_messages = dynamic(['ClientAuthenticationSuccess','UserAuthenticationSuccess']);
SAPBTPAuditLog_CL 
| where SubaccountName == "SAP-AI-Core-playground"
| where Message has_any (login_messages)
| extend ip_ = tostring(Message.ip)
| extend country = geo_info_from_ip_address(ip_)['country']
| where country !in (myBTPDevelopers);

For a smoke test I teleported myself into the land of leprechauns🌈, steep cliffs, and mysterious celtic culture🍀 using an Azure VM. Marvel at the rule that identifies that mischieveous btp user!

Screenshot of found btp login from Ireland

The next sample uses the Threat Intelligence feature to verify if the BTP remote access can be traced back to a feed of known problematic IP indicators (e.g. a bot network). I maintained it on Sentinel on the Threat Management section using the IP known to BTP for my recent logins to the SAP AI Core service to trigger a result. In real life you would take the IPs from a threat intel feed of course. I don't have a bot net handy though😉.

Screenshot of Sentinel Threat Management experience

That makes it available to my Kusto query as below. See below the screenshot of the result:

Screenshot of Kusto query result filtered by problematic IPs

//flag unexpected logins from IP indicators from Sentinel
let ips = ThreatIntelligenceIndicator
| distinct NetworkIP = tostring(NetworkIP);
let login_messages = dynamic(['ClientAuthenticationSuccess','UserAuthenticationSuccess']);
SAPBTPAuditLog_CL
| where SubaccountName == "SAP-AI-Core-playground"
| where Message contains "aicore" and Message has_any (login_messages)
| extend ip_ = trim(" ", replace(@"\s", "", replace(@"\r|\n|\t", "", tostring(Message.ip))))
| join kind=inner (
    ips
    | extend NetworkIP_ = trim(" ", replace(@"\s", "", replace(@"\r|\n|\t", "", tostring(NetworkIP))))
) on $left.ip_ == $right.NetworkIP_;

A natural next evolution of the detection would be to extend it to the "impossible travel" scenario.

These queries are simple to set up and are good to go to serve as new analytics rule on the solution, don’t you think?

Let me know what other scenarios you would like to see 😊

Thoughts on production readiness

SAP’s Audit Log Service is widely adopted across the SAP BTP services and foundational to the platform.

Onboarding your subaccounts and global accounts to Sentinel for SAP BTP eases "subaccount sprawl". Customers with hundreds of subaccounts easily loose sight of what is where and what gets frequented by whom. Such "blind or forgotten spots" lead to exposure that can be prevented.

Sentinel for SAP BTP recently went into “General Availability” state, making it good to use for anyone who doesn’t like previews 😎

To create meaningful detections based on the SAP BTP audit log at minimum other sources, such as the Authorization and Trust Management service (XSUAA) must be considered. Enriching your threat signals with indicators from the rest of your IT landscape gets you from "SAP-security-acolyte"🧑🏻‍🏫 to master of disaster🥷🏼.

The built-in Sentinel for SAP playbooks use SAP BTP public APIs for automatic remediation. See the user API documentation for disabling users here.

Final words

Constantly staying ahead of attackers all the time is impossible. However, putting up a fight so they move on without doing more serious damage or at least being automatically informed about the incident puts you back in the driver’s seat.

The Sentinel for SAP BTP solution enables you to bring the SAP BTP audit log information for cross-correlation with your wider IT landscape to the Microsoft SIEM solution Sentinel. Furthermore, it powers automatic remediations like user block, password reset, and more.

Looking for R3, ERP, S/4HANA, and RISE next? Here you go.

For true confidence in drastic actions like blocking users, you require signals from as many sources as possible. Think beyond the SAP boundary and towards your complete IT landscape: Devices, endpoints, and suspicious logins etc. All of those touchpoints leave a trail of your attacker long before they reach SAP BTP, because of the prior phishing attempts or lateral movement etc. Have a look at Defender XDR for further info.

What detections are you running for your BTP landscape? Let the community know so we can learn from each other’s security practices.

Cheers

Martin

Re: SAP ARIBA integration with a third-party system

2024-08-14T08:27:40.015000+02:00

Hey @Tural-Hajiyev,

SAP integration suite would be a good starting point for your research. Have a look here: https://api.sap.com/package/SAPBusinessNetworkIntegrationwithNonSAPERP/integrationflow

And this older community thread: https://community.sap.com/t5/spend-management-q-a/sap-ariba-integration-with-microsoft-dynamics/qaq-p/12151543

Let the community know what you decided in the end with which public source 🙂

KR Martin

Integrating low code solutions with Microsoft using SAP Integration Suite has never been easier!

2024-08-14T08:50:31.455000+02:00

This blog is co-authored with Vinayak Adkoli (Lead Product Manager, SAP Integration Suite, SAP SE). Link to Microsoft Learn Hub for Power Platform and SAP here🔗.

Dear community,

Extending SAP with low-code platforms significantly increases the speed of development, enabling rapid innovation essential for staying competitive today.

Analysts predict that low code will become the preferred software development method by 2025. (KPMG, 2023)

Forrester approximates the citizen development market to be valued at 30 billion dollars by 2028. (Forrester, 2024)

However, it is crucial to maintain stringent security measures and respect existing SAP authorizations. By doing so, organizations can harness the benefits of low-code development while ensuring the protection and compliance of their SAP environment.

Oh boy, you ready for all the solutions, apps, curious interns, and mad scientists looking to interact with SAP ERP to combine with Microsoft 365? 😮

Fear no more! The API Management capability of SAP Integration Suite is more than ready. In our usual Microsoft + SAP co-engineering fashion, we are proud to jointly release a fully-fledged enterprise-grade API management policy to support the integration pattern.

Architecture overview of low code app using SAP APIM for Principal Propagation

It enables SAP Principal Propagation with SAP services such as SAP Gateway, S/4HANA Cloud, RISE, and many more using Microsoft Entra ID (formerly Azure AD) as Identity Provider. At the core of the solution is the proven OAuth2SAMLBearer flow.

This way users of your low code solutions and apps spanning the Microsoft and SAP ecosystem are mapped from their Microsoft Entra Id identities to their named SAP backend users. SAP authorizations are fully retained!

In addition to that, solving this challenge on Integration Suite level enables scaling the approach to arbitrary many different consumer solutions. No more re-inventing the wheel for every developer!

Find the APIM policy and further guidance here on the SAP Business Accelerator hub.

Note that SuccessFactors requires a slightly different policy.

Of course, you may deviate from the blueprint outlined based on your scenario across SAP BTP, SAP Graph, Integration Suite, other SAP SaaS solutions etc.

Approach	Principal Propagation Scenarios
OAuth2SAMLBearer flow	Service to service, on-behalf-of user
Authorization Code flow	Interactive user session (prone to MFA interference)
Client Credentials flow	Service to service
X.509	Any

We recommend using OAuth2SAMLBearer, because:

The given scenario in this blog is about app integration and identities known to Microsoft Entra ID, for the integration
OAuth2 is more flexible and granular control over access to resources
NetWeaver does not support Client Credentials flow and X509 certificates come with management overhead.

For simplicity and readability of the blog I will refer only to NetWeaver specific settings even though the approach works with any SAP product that supports OAuth2SAMLBearer.

Learn more about this space overall from the blog series by my magnificent colleague Martin Raepple.

A glimpse under the hood

The API Management policy works under the assumption that trust between your OAuth 2.0 Server for AS ABAP and Microsoft Entra ID has been setup before.

Have a look at the developer series on our YouTube playlist for a walk-through experience (be warned this was a “without-script exercise” to show pitfalls and how to overcome).

In addition to the existing authorizations maintained on SAP each application consuming the SAP API proxy from API Management needs to be authorized on Entra ID.

See this official guide for details on the Entra ID SAML2 setup. See the difference for OAuth2SAMLBearer compared to general SAML2 below:

Keep close attention to the Entity ID. It is case sensitive! I chased an error once for half a day because of that.

Be aware that Entity ID must be unique in your Entra ID tenant. In case you want to use SAML2 for Fiori SSO and OAuth2 for SAP Principal Propagation for this SID at the same time, you need to maintain both on the Entra ID enterprise app registration. Assign an order (index) that works with your login flow. See below sample for reference.

Have a look at my video series for a more guided experience on the OAuth2 part. I also like this simple blog series to complete the picture.

Take care of your OAuth settings

The steps for the OAuth configuration may vary a bit by SAP product. Here the focus is on NetWeaver.

Move on to your SAP backend and create a user for your OAuth client. For SAP NetWeaver based systems that will be a user of type system with authorizations for S_SCOPE that are relevant for the OData service you want to expose.

Both the OAuth2 client user and your SAP end user need S_SCOPE authorization.

Use transaction PFCG to assign the authorization objects to your role or create a new one. I like this blog series for reference.

Verify from transaction /n/IWFND/MAINT_SERVICE that your OData service is enabled for OAuth2.

Birds eye🐦 view on the overall process

Below sequence diagram explains an initial login performing SAP Principal Propagation using the OAuth2SAMLBearer flow. There are three requests involved:

1. Low Code app login (Entra ID) invoked by the app

2. Token exchange for a SAML2 assertion (Entra ID on-behalf-of flow) invoked by API Management

3. Token exchange of SAML2 assertion issued by Entra ID to SAP access token issued by SAP OAuth2 server. The request is invoked by API Management. The result is a token carrying the authorizations set on the SAP backend (PFCG transaction) for that end user.

As stated at the beginning, the heavy lifting is done by the provided API Management policy.

Once a bearer access token from SAP is available, all requests can be directly served from the API Management token cache. Once it expires – typically after one hour – the refresh token is used to request a new access token. The same is true for the first login step from the low code app.

Import the policy into your tenant

Download the policy📥 from the SAP Business Accelerator Hub and import the template into your SAP API Management tenant.

Learn more about configuring an API Provider with SAP Cloud Connector on this SAP tutorial.

Apply to all the PostFlow steps of the TargetEndpoints of your APIs as you see fit. See this SAP tutorial and this SAP GitHub repos for more details. The policy requires to run in the PostFlow section in order for the “target.basepath” to be populated.

Consider the governance and security trade-offs between mighty policies and SAP OAuth clients authorized for everything vs. a multitude of clients for each API and scope.

Configure the policy using a key value map

All the configuration needed for earlier shown token exchange flow is best provided with an encoded key value map (I recommend starting with un-encoded one, when you do this the first time for simpler troubleshooting). Create a new encrypted one called “SAPPrincipalPropagationMap”. The name is referenced on the provided policy.

Fill the values as per your environment:

Key	Value sample	Hints
entra-id-tenant-id	12a345bc-1234-56ab-78ab-zzzzzzzzz	Find it on the Azure portal (e.g. here)
issuer	https://sts.windows.net/12a345bc-1234-56ab-78ab-zzzzzzzzz/	The prefix is fixed. Only the tenant id is dynamic. https://login.microsoftonline.com/12a345bc-1234-56ab-78ab-zzzzzzzzz for v2 endpoints
entra-id-audience	api://999abce-7777-abcd-a6c9-zzzzzzzzzzz	The globally unique Application ID URI from the Entra ID app registration representing your SAP API Management instance
AADRegisteredAppClientId	999abce-7777-abcd-a6c9-zzzzzzzzzzz	The Application (client) id of the Entra ID app registration representing your SAP API Management instance.
AADRegisteredAppClientSecret		The secret created for the application 999abce-7777-abcd-a6c9-zzzzzzzzzzz
AADSAPResource	https://a4h100	The provider’s name from your NetWeaver SAML setup. Typically, a URL with SID followed Client number
sap-oauth-client-username	ODATAOAUTH	User name provided on SOAUTH2 transaction (/sap/bc/webdynpro/sap/oauth2_config?sap-client=100) Create a system user on SU01 with minimum rights (S_SCOPE) and reference that on SOAUTH2. Don’t forget to assign authorized scope.
sap-oauth-client-password		This is only used to request tokens not to authenticate to SAP.
sap-oauth-scope	ZPRODUCTSVIEW_CDS_0001	The scope assigned on SOAUTH2. If multiple make a space-separated list.
SAPOAuthServerAdress ForTokenEndpoint	a4h-internal.cloudapp.net:44301	Host and port of the target SAP OAuth server. When cloud connector is used, put the virtual hostname and port.

Adjust the name of the API provider as per your setup in the policy elements “RefreshSAPToken”, “fetchSAPOAuthToken”, and “GetCSRFToken”.

SAP Cloud Connector settings are minimal

In this scenario all authentication means are done by the SAP API Management policy. Therefore, the configuration for the connected on-premises API provider (your SAP Cloud Connector) is reduced to the host and port only.

Keep Authentication on NONE. But be assured that the OAuth2SAMLBearer flow has your back. Additional auth config on the Cloud Connector would either be redundant or interfere with the setup.

Note: The Principal Propagation option on the Cloud Connector connection config uses short-lived X.509 certificates and the purpose of the scenario outlined in this blog was about API only approaches.

Authorize the consuming application with API Management

Authorize the Power Automate SAP OData connector to request tokens for your API Management instance using its client id: 6bee4d13-fd19-43de-b82c-4b6401d174c3 assigning the user_impersonation scope.

Verify the id from the Microsoft docs.

Next, verify the client id of your API Management instance is authorized on the app registration attached to your target SAP product (in my sample SAP NetWeaver). And because I was lazy, I gave it the same name. Check the required scope is ticked too ("Scopes = 1" on the bottom table of the screenshot below).

Be aware that your internal policies might require you to actively assign users or groups to the enterprise app registration. Otherwise, you will get an error before you even get to SAP. Been there, done that. Just saying 😉

The final mile of integration

Ok, all homework is done. Now we get to go outside and enjoy the “low code” sun 🌞 Create your SAP OData connection, choose the authentication type Microsoft Entra ID and paste the URI of the Entra ID app registration that represents your API Management.

Clicking on Sign in triggers the $metadata request to your OData endpoint to pull available values.

The connection is now authorized with the user you supplied. However, each user with whom the flow is shared will be authorizing its use of the connection on first call again with their identity.

Hints on troubleshooting

SAP’s OAuth server has a tracing tool provided as WebDynpro.
- Open it from SAPGUI with transaction sec_diag_tool or navigate to the web app: /sap/bc/webdynpro/sap/sec_diag_tool?sap-client=YYY
- Search for error messages and successful mapping of the Entra ID provided email to the SAP backend user.

All the settings are client dependent! Always double check it is being applied (or add sap-client URL parameter to be sure). Been there done that 😉 See below transactions to verify setup:
- SAML2 or the webdynpro: /sap/bc/webdynpro/sap/saml2?sap-client=YYY
- SOAUTH2 or the webdynpro: /sap/bc/webdynpro/sap/oauth2_config?sap-client=YYY

Before applying the APIM policy consider running the sequence of authentication calls locally (with “line of sight” to NetWeaver of course) using a REST client. See this Postman collection for reference. Verify errors from transaction /n/IWFND/ERROR_LOG. Drop cookies in your REST client before re-testing!

Verify the produced Entra ID tokens attributes using a safe JWT validator (e.g. DevToys). Don’t share your sensitive tokens on some website for validation!
- iss (Issuer): Should read something like https://sts.windows.net/12a3456-zzz... or https://login.microsoftonline.com/12a3456-zzz... for v2 endpoints.
- aud (Audience): Something like “api://bbbbbb-cccc-dddd-dddd-eeeeeeee”
- scp (Scope): “user_impersonation”

For the SAML2 assertion exercise the same approach but do base64 decode and XML pretty print. Notepad++ with MIME tools -> Base64 decode and XML Tools -> pretty print does the job locally just fine. Again, don’t paste sensitive info online! Verify the following claims from your assertion:
- AudienceRestriction -> Audience: Should be a URL containing your SID and client id, e.g. https://A4H100
- Claims: Name, email or whatever you have configured to be used to identify the named SAP backend user.

While doing integration tests with the API Management policy consider decoding the key value map or use a public one till you are confident with your setup to see immediately what config values were provided.

Verify that your key value map changes are being pulled.

Cached a faulty token? Disable the caching policy step "LookupSAPTokens" and "LookupSAPRefreshTokens" using the enabled attribute on the XML or consider adding an API to clear the cache by user using the "InvalidateCache" policy step.

405 Method Not allowed (SAP note 3386802😞 SAP API Management generates PUT method entries for OData v2 and PATCH entries for OData v4 services. Power Automate's "Update entity" step uses the PATCH approach. In case of conflict, either choose the "Create any type of OData request" step and configure PUT instead on Power Automate or adjust the swagger definition using "Edit in API Designer" on SAP API Management to add PATCH to cater for this.

POLICY_PARSING_ERROR: In case you encounter a generic "Unable to update API", make sure you have maintained a correctly named APIProvider attribute under HTTPTargetConnection entity. It is being refrenced in multiple ServiceCallout steps!

Thoughts on production readiness

SAP Integration Suite is more than ready for prime time as the de-facto standard for SAP heavy integrations.

The OAuthSAML2Bearer flow is an ever green discussed in the community at length for years and fully supported by SAP for service to service Principal Propagation.

The involved Entra ID app registration client secret can be governed with Azure automation or SAP Build Apps Process Automation. See this Microsoft article and this GitHub repos for reference.

Applying the battle-proven API management policy from the API hub ensures a configuration driven approach and clear update paths.

The SAP and Microsoft low code eco system is a natural fit for productivity across business needs that involve M365 (Microsoft Graph, Teams, Outlook, SharePoint Online, etc.) and SAP.

In terms of governance, SAP offers extensive integration with the Microsoft ecosystem. See this co-authored blog about SAP API Management integrating Azure APIs and this one about Azure API Center to handle a multitude of gateways in a single place.

Final Words

That’s a wrap 🌯. Today you saw how to configure SAP Principal Propagation with Microsoft Entra ID for low code solutions. The approach maps Microsoft identities to SAP named users to retain its SAP authorizations. In addition to that you learnt that a provided SAP API Management policy performs the heavy lifting of the authentication flow.

App developers and low coders no longer need to deal with the complexity of the principal propagation and get added benefit of token caching, token refresh, and CSRF handling out-of-the-box. Find the policy on the SAP Business Accelerator hub.

Get started from here.

Cheers

@vinayak_adkoli and Martin

Re: Bring the data from Azure DataBricks (ADB) to SAP ABA...

2024-08-23T08:08:03.769000+02:00

Have you considered the ABAP SDK for Azure? It has accelerator code for your scenario.

I believe you will find the REST API descriptions here.

Cheers Martin

Re: Bring the data from Azure DataBricks (ADB) to SAP ABA...

2024-08-27T07:56:18.078000+02:00

Yes, the accelerator code on the ABAP SDK is aimed at connecting to Azure services for pull based approaches. That was the first request on your list. Connection direction does not mean you cannot get the data. The SDK is pull-oriented but of course its code can be used for push-based too. You may connect to ADB REST api for instance and handle Managed Identities, Entra ID authentication flows etc out-of-the-box from ABAP.

Push based approaches require a completely different stack with transformations and coding your receiver on ABAP. And we haven't started discussing retry logic and mass data movement yet 😄 at that point a thread of comments is no longer suitable to arrive at a sustainable solution.

Re: SAP Private linky swear with Azure – running Cloud Connector and SAP Private Link side-by-side

2024-11-19T11:59:03.301000+01:00

Hey @MofizurRahaman,

there is not much more that can be said about as the blog already states.

1. SAP PLS is no replacement of the SCC. You are comparing a networking service with a software product that includes audit logging, selective RFC exosure etc. They are complementary rather than competitive. Hence, the roadmap item to enable the SCC to communicate with BTP over PLS.

2. SAP PLS supports principal propagation of course, because it is a networking solution. This space has likely evolved since my last post on it but the approach still holds true. See blog part 5.

3. This depends on your own needs. No official guidance published yet.

Let the community know what you decided in the end 🙂

Perform SAP Principal Propagation with Microsoft Entra ID for SAP SuccessFactors!

2024-11-20T10:09:24.231000+01:00

This blog is co-authored with Vinayak Adkoli (Lead Product Manager, SAP Integration Suite, SAP SE). Link to Microsoft Learn Hub for Power Platform and SAP here🔗.

Dear community,

The last blog post showed how to integrate Microsoft and SAP low code solutions with SAP services using the API Management capability of SAP Integration Suite and Microsoft Entra ID as identity provider overall. Todays post is about the specifics for SAP SuccessFactors.

Spoiler alert🤫: the approach stays the same! Only a slightly modified API Management policy needs to be imported. SuccessFactors uses API keys for its SAML assertions rather than an OAuth2 client id and contains your SuccessFactors company id.

Technically you could use the same policy for NetWeaver based systems and SuccessFactors, because the “unexpected” authentication attributes are ignored as of the releases that were tested. It is a good practice though to separate the concerns. Therefore we published a separate policy instead of a one-size-fits all one with bloated number of attributes.

At the core of the solution is again the proven OAuth2SAMLBearer flow. See the official SuccessFactors docs on the required SAML attributes for reference.

In addition to that, solving this challenge on Integration Suite level enables scaling the approach to arbitrary many different consumer solutions. No more re-inventing the wheel for every developer!

Find the SuccessFactors specific policy on the SAP Business Accelerator Hub.

Of course, you may deviate from the blueprint outlined based on your scenario across SAP BTP, SAP Graph, Integration Suite, other SAP SaaS solutions etc.

A glimpse under the hood

Start your journey on SAP API Management by creating a new API provider for your SuccessFactors tenant. Be aware☝️ of the different domains for the portal UI and the associated OData API endpoint! See SAP note 2215682 for reference.

Next, register your SuccessFactors OData API. In my sample I am taking the entity set “User”, that resides on the base path for a tenant in DC5 like so:

https://api5.successfactors.eu/odata/v2/User/$metadata

Make sure to verify the base path of the URL (/odata/v2 vs. /odata/v2/User) of your target endpoint on API Management. See below Screenshot for reference.

Otherwise, you will encounter routing issues for request like /odata/v2/User(‘1000’).

The API Management policy works under the assumption that trust between your SAP SuccessFactors OAuth2 server and Microsoft Entra ID has been setup before. See this guide for reference.

In addition to the existing authorizations maintained on SuccessFactors each application consuming the SAP API proxy from API Management need to be authorized on Entra ID.

See this official guide for details on the Entra ID setup. Be aware the linked guide refers to the SAML2 setup (not OAuth2!). See the difference for OAuth2SAMLBearer below:

The Entity ID can be any URI. It is a good practice though to use something that resembles your SuccessFactors tenant.

Be aware that Entity ID must be unique in your Entra ID tenant. In case you want to use SAML2 for SSO and OAuth2 for SAP Principal Propagation for this tenant at the same time, you need to maintain both on the Entra ID enterprise app registration. Assign an order (index) that works with your login flow.

Take care of your OAuth settings

The steps for the OAuth configuration may vary by SAP product. Here the focus is on SAP SuccessFactors.

Move on to your SuccessFactors tenant and open the app “Manage OAuth2 Client Applications” to create a new OAuth client for your Microsoft Entra ID enterprise app. Populate the values as per your environment.

Be aware that you need to copy the certificate body only without the header -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.

Import the policy into your tenant

Download the policy from the SAP Business Accelerator Hub and import the template into your SAP API Management tenant.

Apply to all the PostFlow steps of the TargetEndpoints of your APIs as you see fit. See this SAP tutorial and this SAP GitHub repos for more details.

Consider the governance and security trade-offs between mighty policies and SAP OAuth clients authorized for everything vs. a multitude of clients for each API and scope.

Configure the policy using a key value map

Fill the values as per your environment:

Key	Value sample	Hints
entra-id-tenant-id	12a345bc-1234-56ab-78ab-zzzzzzzzz	Find it on the Azure portal (e.g. here)
issuer	https://sts.windows.net/12a345bc-1234-56ab-78ab-zzzzzzzzz/	The prefix is fixed. Only the tenant id is dynamic. https://login.microsoftonline.com/12a345bc-1234-56ab-78ab-zzzzzzzzz for v2 endpoints
entra-id-audience	api://999abce-7777-abcd-a6c9-zzzzzzzzzzz	The globally unique Application ID URI from the Entra ID app registration representing your SAP API Management instance
AADRegisteredAppClientId	999abce-7777-abcd-a6c9-zzzzzzzzzzz	The Application (client) id of the Entra ID app registration representing your SAP API Management instance.
AADRegisteredAppClientSecret		The secret created for the application 999abce-7777-abcd-a6c9-zzzzzzzzzzz
AADSAPResource	https://my.successfactors.eu	The provider’s name from your SuccessFactors SAML setup.
sap-oauth-sf-api-key	ABCDE1234FGH6789	API Key generated by SuccessFactors for your OAuth2 application. Instructions here.
sap-oauth-company-id	SF123456	Your SuccessFactors Company id. Find here.
SAPOAuthServerAdress ForTokenEndpoint	salesdemo.successfactors.eu	OAuth endpoint of your successfactors instance.

Adjust the name of the API provider as per your setup in the policy elements “fetchSAPOAuthToken”, and “GetCSRFToken”.

The final mile of integration

Ok, all homework is done. Now we get to go outside and enjoy the “low code” sun with SAP SuccessFactors 🌞Create your SAP OData connection in Power Automate, choose the authentication type Microsoft Entra ID and paste the URI of the Entra ID app registration that represents your API Management.

Hints on troubleshooting

Before applying the APIM policy consider running the sequence of authentication calls locally (with “line of sight” to NetWeaver of course) using a REST client. See this Postman collection for reference.

Verify the produced Entra ID tokens attributes using a safe JWT validator (e.g. DevToys). Don’t share your sensitive tokens on some website for validation!
- iss (Issuer): Should read something like https://sts.windows.net/12a3456-zzz... or https://login.microsoftonline.com/12a3456-zzz... for v2 endpoints.
- aud (Audience): Something like “api://bbbbbb-cccc-dddd-dddd-eeeeeeee”
- scp (Scope): “user_impersonation”

For the SAML2 assertion exercise the same approach but do base64 decode and XML pretty print. Notepad++ with MIME tools -> Base64 decode and XML Tools -> pretty print does the job locally just fine. Again, don’t paste sensitive info online! Verify the following claims from your assertion:
- AudienceRestriction -> Audience: Should be a URL containing your app id, e.g. https://my.successfactors.eu
- Claims: Name, email or whatever you have configured to be used to identify the named SAP backend user.

While doing integration tests with the API Management policy consider decoding the key value map or use a public one till you are confident with your setup to see immediately what config values were provided.

Verify that your key value map changes are being pulled.

Cached a faulty token? Disable the caching policy step "LookupSAPTokens" using the enabled attribute on the XML or consider adding an API to clear the cache by user using the "InvalidateCache" policy step.

405 Method Not allowed (SAP note 3386802 SAP API Management generates PUT method entries for OData v2 and PATCH entries for OData v4 services. Power Automate's "Update entity" step uses the PATCH approach. In case of conflict, either choose the "Create any type of OData request" step and configure PUT instead on Power Automate or adjust the swagger definition using "Edit in API Designer" on SAP API Management to add PATCH to cater for this.

Thoughts on production readiness

SAP Integration Suite is more than ready for prime time as the de-facto standard for SAP heavy integrations.

The OAuthSAML2Bearer flow is an ever green discussed in the community at length for years and fully supported by SAP for service to service Principal Propagation.

The involved Entra ID app registration client secret can be governed with Azure automation or SAP Build Apps Process Automation. See this Microsoft article and this GitHub repos for reference.

Applying the battle-proven API management policy from the API hub ensures a configuration driven approach and clear update paths.

PowerAutomate also supports Principal Propagation with SuccessFactors directly. However, that would be a point-to-point integration without the governance and security benefits of having an API Management solution in between.

The SAP and Microsoft low code eco system is a natural fit for productivity across business needs that involve M365 (Microsoft Graph, Teams, Outlook, SharePoint Online, etc.) and SAP.

Final Words

That’s a wrap 🌯. Today you saw how to extend the learnings from the first blog to enable SAP SuccessFactors for Power Automate with Principal Propagation through Microsoft Entra ID. The approach maps Microsoft identities to SAP named users to retain its SAP authorizations. In addition to that you learnt that a provided SAP API Management policy performs the heavy lifting of the authentication flow.

App developers and low coders no longer need to deal with the complexity of the principal propagation and get added benefit of token caching, and CSRF handling out-of-the-box.

Get started from here.

#Kudos to Martin Raepple for the contribution of the tricky part of the token dance.

Cheers

@vinayak_adkoli and Martin

Re: SAP API Management - OAuth 2.0 authentication with Su...

2024-11-20T10:15:18.334000+01:00

Here is the blog that references the new policy on Entra ID + SuccessFactors: https://community.sap.com/t5/technology-blogs-by-members/perform-sap-principal-propagation-with-microsoft-entra-id-for-sap/ba-p/13860532

Re: SAP API Management - OAuth 2.0 authentication with Su...

2024-11-21T10:41:34.338000+01:00

Hey Faisal, the difference is who is in charge of generating/signing the SAML assertion and who handles secrets for the trust relationship. Only IdPs are trustworthy in that sense.

Re: It has never been easier to print from SAP with Microsoft Universal Print

2024-12-12T14:55:30.019000+01:00

Hey @Martin-Frick, hope you are enjoying down under.

Microsoft Universal print as per our docs article uses the browser and OS functionalities for cloud printing from Fiori apps. What made you think otherwise? Do we need to update materials maybe?

KR Martin

Microsoft Sentinel for SAP goes agentless

2024-12-17T08:53:02.437000+01:00

What a title during Agentic AI times 😂

Dear community,

Bringing SAP workloads under the protection of your SIEM of choice is a primary concern for many customers out there.

The window for defenders is small

“Critical SAP vulnerabilities being weaponized in less than 72 hours of a patch release and new unprotected SAP applications provisioned in cloud (IaaS) environments being discovered and compromised in less than three hours.” (SAP SE + Onapsis, Apr 6 2024)

Having a turn-key solution as much as possible leads to better adoption of SAP security. Agents running in Docker containers, Kubernetes, or other self-hosted solutions are not for everyone.

Microsoft Sentinel for SAP’s latest capability re-uses the SAP Cloud Connector to profit from already existing setups, established integration processes, and well-understood SAP components. Bazinga💥

Meet agentless❌🤖

The new integration path leverages SAP Integration Suite to connect Microsoft Sentinel with your SAP systems. The Cloud integration capability of SAP Integration Suite speaks all relevant protocols, has connectivity into all the places where your SAP systems might live, is strategic for most SAP customers, and is fully SAP RISE compatible by design.

Best of all: The already existing SAP security content (detections, workbooks, and playbooks) in Microsoft Sentinel continues to function the same way as it does for the Docker-based collector agent variant.

During the private preview we saw drastically reduced deployment times for SAP customers being less familiar with Docker, Kubernetes and Linux administration. Cherry on the cake: the network challenges don’t have to be tackled again. The people running your SAP Cloud Connector went through that process a long time ago. 🤘SAP Basis rocks🤘

Ok, hook me up!

Customers on SAP NetWeaver 750+ may simply create additional configuration on their SAP Cloud Connector. A small set of RFC function modules are required to be reachable from SAP Integration Suite. Verify from the Sentinel documentation for the latest info.

Depending on your SAP version, you might need to install SAP note 3054326 to enable the remote call of the audit log API

Move on to the Destination maintenance view on your Subaccount on SAP Business Technology Platform. Add an RFC connection matching the details of your SAP Cloud Connector configuration. Consult SAP’s official documentation for more details.

Finish the exercise by providing a user on SAP with the required authorizations to call the mentioned remote function modules. Find a transport to bring a pre-configured role here for your convenience.

Everyone else below SAP NetWeaver 750, reach out to us to talk more details for older AS ABAP releases. Given the audit log API evolution, a different configuration for the integration package is required.

Community Extensions - Because Security is a Team Sport 🤝

The Microsoft Sentinel for SAP journey doesn't stop with official Microsoft offerings in SAP Integration Suite! We are expanding the proven community track to the agentless approach. Build on top of the platform to further enhance your SAP security operations tailored to your needs.

Partners, ISVs, and first and foremost customers are invited to share, contribute, and request additional artifacts.

Check out the Sentinel For SAP Community repository where you'll find the first set of Integration templates for you to build upon for additional security workflows.

What is already there?

The solution package features an SAP Integration Suite integration flow for SOAR use cases. With that you may re-use the same integration approach that the agentless data connector uses. This means requesting SAP user blocks or SAP audit log reactivation can now be done without any additional proxies like Microsoft On-premises-Data-Gateway, separate virtual network injection or the likes. Not too bad, huh?

I especially love seeing customers and partners contributing their expertise to make SAP environments more secure for everyone. This is what community is all about!

Thoughts on production readiness

SAP Integration Suite and SAP Cloud Connector are among the most used SAP Cloud components for decades now and are completely ready for prime time as they say.

The new agentless offering of the Microsoft Sentinel for SAP solution is currently in preview but reuses fully mature capabilities and leverages existing security content. It will be expanded based on your feedback and requirements.

The integration marks your steppingstone to bring your SAP threat signals into the Unified Security Operations Platform – a combination of Defender XDR and Sentinel – that looks beyond SAP at your whole IT estate.

Microsoft Sentinel solution for SAP applications is certified for SAP S/4HANA Cloud, Private Edition RISE with SAP, and SAP S/4HANA on-premises. So, you are all good to go 😎

Final Words

That’s a wrap 🌯. You learned today:

All there is to know about going agentless with the Microsoft Sentinel for SAP solution,
Where to find community extensions to the official Microsoft integration package to extend with your own flows on SAP Integration Suite,
How important it is to bring SAP under the protection of your central SIEM, and that
Leveraging existing SAP integration components gets you up and running securely, SAP RISE future proof, and in no time.

Get started from here.

#Kudos to the amazing Sentinel team!

Cheers

Martin

Getting Started with SAP SNC for RFC integrations

2025-01-12T17:20:02.514000+01:00

Dear community,

Many of you still rely heavily on the legacy SAP interface RFC. In my world that often means customers connecting their third-party services to SAP backends (AS ABAP). Securing a protocol such as SAP Remote Function Call (RFC) requires network layer protection.

Often Kerberos is discussed on this topic, because it allows the mapping of Windows-Known identities to SAP backend users. However, this post is about apps and technical connections using X.509 certs – not people. They complain less – and boringly but reliably behave the same way once configured properly😉 Meet SAP Secure Network Communications (SNC).

By the way: In case you want user-based flows and focus on SAP Principal Propagation have a look at this series by my beloved colleague Martin Raepple.

SAP SNC integration architecture overview

Welcome to the world of SAP Secure Network Communications (SNC) for trustworthy technical connections!

In light of zero-trust efforts customers want to secure their technical connections to SAP RFCs too. In that space certificate-based authentication mechanisms are king. SNC is a prominent choice.

There are libraries for languages like Java, DotNet, C/C++, Python, and NodeJS that support SNC for RFC. Python and NodeJS were recently archived and will no longer be maintained. In case you get stuck, consider generating SOAP services for your SAP RFCs to uplevel the communication stack to layer 7 for use with TLS instead.

Source: SAP Help

Below I will show a simple setup with self-signed certificates. This way you can get started with a working setup and elevate towards more sophisticated as you go. Troubleshooting SNC errors can be cumbersome, so starting small with less variables and less room for error is a good idea.

Be aware of latest crypto library guidance (SAPCryptoLib vs, CommonCryptoLib) published by @JoeGoerlich in this post. Verify your archive name starts with SAPCRYPTOLIB_*.sar (which refers to CCL 8.x).

First things first: reach your private RFC interface

SAP products like the SAP Cloud Connector support apps (and people) on the SAP Business Technology Platform to connect to private instances of AS ABAP systems (behind firewall, in RISE, on-premises, or on a protected hyperscaler environment) and bring the required RFC execution environment.

Third-party apps must overcome the same challenges. Typically, that means you will be provided with a piece of software to act as reverse invoke proxy (same as the SAP Cloud Connector) besides the “line of sight” through connected private networks from that proxy. See step 0 in the overview drawing for reference.

It establishes connection to your third-party app inside out, so that no inbound firewall rules or the likes need to be touched.

For instance, Microsoft apps like Azure Data Factory, Azure Synapse, Microsoft Purview, Microsoft Fabric, and Microsoft Power BI have dedicated means to connect. These components are called Self-hosted Integration Runtime (SHIR) or On-Premises Data Gateway. Find the downloads on the individual product pages.

Be aware that services like Azure Functions or Azure LogicApps have a second approach beyond the Microsoft On-premises Data Gateway. They can bring the means to execute RFC calls, provide SNC configuration, and create line-of-sight to the private network through injection capability in a single deployment. This way you don't need the reverse invoke proxy.

Each of the described solutions have individual guides on the SAP RFC setup and how to expose the configuration for SAP SNC.

Can highly recommend my colleague Taylor Brazelton’s blog for SNC from Power Platform and On-premises Data Gateway.

Find below an SAP SNC config sequence with self-signed certificates generated by OpenSSL. Through this setup AS ABAP accepts requests protected by SNC via the SHIR.

I assume you have already installed the SHIR on a suitable windows machine and taken care of required installations like SAP Java Connector (JCo), SAP Connector for Microsoft .NET (NCo), and .NET Framework. My samples and script commands are Windows specific. However, Linux works the same way with slightly different commands.

Download SAP SNC Crypto Lib to your SNC client machine

Search the latest “SAPCRYPTOLIB” on SAP’s software center (S-User with download rights required)
And extract the SAR file using SAPCAR. Command looks something like this:

.\SAPCAR_1200-70007719.EXE -xvf .\SAPCRYPTOLIBP_8553-20011729.SAR -R .\..\libs\sapcryptolib

Find the executable sapgenpse

Prepare your SNC client machine

Create a folder to hold your SAP PSE artifacts:

mkdir sapsecudir
cd .\sapsecudir

Permanently add environment variable to point at this folder

[Environment]::SetEnvironmentVariable("SECUDIR", "C:\sapsecudir", "Machine") # Sets the variable permentaly on the system.
$env:SECUDIR = "C:\sapsecudir" # Updates the current powershell session as there currently does not exist a function to reload.

Generate a certificate for your SNC client app

Create folders to hold your certificates: mkdir rootCA sncCert
Generate root CA certificate: Adjust the subject as needed

openssl genpkey -algorithm RSA -out rootCA/ca.key.pem -pkeyopt rsa_keygen_bits:2048 

openssl req -x509 -new -key rootCA/ca.key.pem -days 7305 -sha256 -extensions v3_ca -out rootCA/ca.cert.pem -subj "/O=Contoso/CN=Root CA"

Generate SNC client certificate and adjust subject as needed:

openssl genrsa -out sncCert/snc.key.pem 2048

openssl req -key sncCert/snc.key.pem -new -sha256 -out sncCert/snc.csr.pem -subj "/O=Contoso/CN=SNC"

Sign the SNC certificate with the root CA certificate:

openssl x509 -req -in sncCert/snc.csr.pem -days 3650 -CA rootCA/ca.cert.pem -CAkey rootCA/ca.key.pem -CAcreateserial -out sncCert/snc.cert.pem

Establish trust between SNC client and SAP

Add the SNC cert to a PKCS #12 archive file (.p12)

openssl pkcs12 -export -out snc.p12 -inkey sncCert\snc.key.pem -in sncCert\snc.cert.pem -certfile rootCA\ca.cert.pem

Create the SAP Personal Security Environment (PSE) using the container

.\sapgenpse.exe import_p12 -p SAPSNCSKERB.pse C:\Users\shir-admin\Documents\snc.p12

Verify SAP is configured for SNC yet

One way of doing that is using transaction RZ10 and browsing the parameters prefixed with SNC. See this SAP document on the required “SNC Parameters for X.509 Configuration” settings and their implications.

If there is no configuration yet execute the transaction SNCWIZARD and maintain settings for X.509 credentials. Take note of the SNC private key subject. The CN will be required later.

Add your SNC client (I named mine PRV for Microsoft Purview) to the SAP Access Control List (ACL) using transaction SNC0 and allow RFC and CPIC connections.

Import SNC client cert into SAP

Use transaction STRUST
Navigate to the instance below SNC SAPCryptolib (if crossed out with a red X, create one from right-click)
Scroll down below the certificate list pane, choose import certificate and supply your snc.cert.pem file.
Click “Add to Certificate List” button
Click “Save”.

Download SAP cert and import into SNC client PSE

From the same STRUST screen, double click the Subject line of “Own Certificate” and
Scroll down again to find the “Export Certificate” button at the bottom.
Move to your SNC client machine (where your SHIR runs), put the certificate in a secure place (in my sample it landed in a folder called sap) and run below command to import it into your PSE.

sapgenpse.exe maintain_pk -p SAPSNCSKERB.pse -v -a  C:\sap\contoso-public-key.crt

Now your SAP trusts connections coming from your SHIR.

Allow your SHIR process to use your SAP PSE

Verify which user or service is being used by your SNC client to obtain certificate to communicate with SAP. The Purview SHIR uses the service user “NT SERVICE\DIAHostService”.
Add a credential to allow the certificate retrieval request from the PSE.

.\sapgenpse.exe seclogin -p C:\sapsecudir\SAPSNCSKERB.pse -x your-pse-pin -O "NT SERVICE\DIAHostService"

Verify credentials like so

.\sapgenpse.exe seclogin -l -O "NT SERVICE\DIAHostService"

You can delete them like this:

.\sapgenpse.exe seclogin -d -O " NT SERVICE\DIAHostService "

Use the -h parameter to get help with the sapgenpse command line tool or check the command reference here.

Test communication using SAP SNC

Navigate to your client application and supply the SNC configuration you have prepared. Some apps require an SAP user and password in addition even though providing a client certificate would be enough for a technical connection (remember: no user mapping or SSO).

This gives you the option to further trim down access. Use transaction SU01 and the SNC tab or the maintenance view “VUSREXTID” from transaction SM30 to configure the SNC external ID (CN) to your SAP user name.

See below sample taken from the connection configuration fly-out pane on the Azure portal UI. It can be applied, however, to any SNC client configuration. See further samples here and here.

Trigger “Test connection” and marvel at the SNC secured communication test from Microsoft Purview to AS ABAP😊

Or go even a step further and call your first RFC. RFC_PING or STFC_CONNECTION might be a suitable one in case your target is not yet operational or not identified yet.

Hints on Troubleshooting

First, try to connect from your client to AS ABAP without SNC to ensure that networking is properly configured already. Be aware of SAP RFC ports (ZZ placeholder represents your SAP instance number, e.g. 00 or 01 often) and check firewall accordingly if needed.
- 32ZZ and 33ZZ for direct RFC connections
- 48ZZ for SNC secured RFC connections
Verify SNC status from transaction SM51 -> click “SNC Status” button to ensure it is fully configured
Consult the blog series from @Frank_Buchholz on more sophisticated approaches to verify individual SNC connections. For instance, report “ZSM04000_SNC” shows more details.
For those of you using SAP UCON may consult the SNC connectivity status there.
Closing above mentioned RFC ports (32ZZ, 33ZZ) on the proxy VM firewall does the trick to verify if SNC connection is opened. Intentionally “breaking” your SNC config by mistyping the SNC partner name for instance could give you another indication on a functional setup.

Final Words

That’s a wrap 🌯. You learned today how to secure your technical RFC connections from third party apps to AS ABAP systems using SNC. The guide keeps it simple so you can establish a stable setup base from which to iterate on more complex setups confidently 😊Generate SOAP services for your RFCs and use TLS in case SNC is not an option.

By the way: When introducing an API Management solution between your 3rd party app and the SOAP service on AS ABAP you may use OAuth2, or OpenID Connect on the client. You still need to translate on the API Management layer to an auth mechanism that AS ABAP supports. Either way a step forward in securing your SAP connections.

Happy integrating with SAP!

#Kudos again to Savas Akgol, @MartinRaepple, and @Frank_Buchholz for helping with some of the hard parts 🙏

Cheers

Martin

Re: SAP Private Link service use cases for SAP Cloud Integration and SAP Build Work Zone, Standard E

2025-01-30T13:33:46.793000+01:00

Hey @MMZ,

BTP endpoints including SAP Cloud Integration are internet-facing by design - like any other SaaS product out there. No way to make that private. SaaS security is about securing app layer not network.

Depending on your scenario you might consider using a timer trigger on your iflow to avoid having an endpoint outside.

KR Martin

Re: Getting Started with SAP SNC for RFC integrations

2025-02-10T13:39:34.046000+01:00

Thank you so much for sharing @JoeGoerlich! Will make a note on the post.

KR Martin

Re: SAP Private linky swear with Azure – running Cloud Connector and SAP Private Link side-by-side

2025-03-06T15:45:42.547000+01:00

@saurabhkumbhare scenario 1.5 is about enabling the Cloud Connector relay connection to be established via Private Link rather than outbound Internet.

CPI to ECC is a different scenario and already covered here.

KR Martin

Re: SAP Private Link service use cases for SAP Cloud Integration and SAP Build Work Zone, Standard E

2025-03-31T16:23:42.443000+02:00

@stag_pune SAP BTP is a Internet-facing app by design. SAP Private Link is the only option for hyperscaler specific private networking options by the platform uni-directional from BTP. Some individual SAP SaaS apps implemented further options for VPN or ExpressRoute without BTP as a platform. As it stands today you need to file a feature request to SAP to request further private networking features.

SAP Principal Propagation without Secrets: How Managed Identity in APIM Simplifies Everything

2025-05-02T11:01:42.574000+02:00

Dear community,

SAP Principal Propagation (for simplicity often also referred to as SSO) is the gold standard for app integration – especially when it comes to 3rd party apps such as Microsoft Power Platform. Building on top of my prior blog on API Management usage for SAP SSO, I am sharing today how you can fully eliminate the passwords or certificates for the token exchange previously required.

No more password storing or rotation. No certificates to renew. No manual key rollover scripts.

Thank god!

The Microsoft Entra ID authentication handshakes with services such as SAP BTP, SuccessFactors, Azure, or M365 apps like Power Platform allows these apps to become native, dynamic, and self-maintaining.

This shift not only tightens security by reducing the attack surface but also significantly accelerates project delivery, improves compliance with modern Zero Trust principles, and cuts down on administrative overhead. It’s a small architectural change with a big real-world impact — and a logical next step for enterprise-grade app integrations in the SAP ecosystem.

A glimpse under the hood

The magic? It’s called Managed Identity for Azure. With a user-assigned managed identity in API Management, the platform takes care of the authentication for you — clean, automatic, and secret-free. Building on top of Workload Identity Federation enables using a managed identity as a credential, just like certificate or password, on Entra ID Applications.

See following updated flow diagram from the prior blog. It highlights with red and yellow arrows where it was possible to “eliminate” credentials.

When browsing Microsoft Learn or additional blogs, look for the technical term “Federated Identity Credential” for additional details.

Solving this challenge on Azure API Management level enables scaling the approach to arbitrary many different consumer solutions.

Find the updated policy on the Azure API Management repos for SAP ECC and S/4HANA here and for SuccessFactors here.

Learn more about this space in general from the blog series by my magnificent colleague Martin Raepple.

Create a user-assigned managed identity for your Azure API Management instance

See additional details on this Microsoft Learn article.

Create a “managed credential”

This step is being referred to by Microsoft Learn as Federated Identity Credential (FIC).

Click Add Credential as per below screenshot from the manage secrets pane of your Entra ID app registration which represents your API Management instance.
Choose scenario “Managed Identity”,
Select the id of your user-assigned-managed identity created before, and
Make sure the audience is listed as “api://AzureADTokenExchange”.

Import the updated policy

Navigate to your SAP OData API on Azure API Management and use the Azure portal UI to paste the policy as code, or leverage infrastructure-as-code with your devops pipeline to apply SAP Principal Propagation at scale. See this Azure Developer CLI sample using Bicep for reference.

See the APIM policy line doing the magical managed identity request. It is as simple as that:

<authentication-managed-identity resource="api://azureadtokenexchange" client-id="{{APIMUserAssignedManagedIdentityId}}" output-token-variable-name="msi-access-token" ignore-error="false" />

The rest happens under the hood.

Learn more about policy creation including Microsoft Copilot usage from this article and this video. In case you fancy GitHub Copilot apply the VS Code extension. See this community post for further inspiration.

Consider the governance and security trade-offs between mighty policies and SAP OAuth clients authorized for everything vs. a multitude of clients for each API and scope.

Configure the policy using named values

The configuration exercise is 99% the same as outlined in the earlier blog “SAP OData connector now supports OAuth2 and SAP Principal Propagation” before. However, now we replace the client secret setting for the Entra ID app registration that represents your API Management instance with the client id of your user-assigned managed identity.

Fill the values as per your environment:

Key	Value sample	Hints
AADTenantId	12a345bc-1234-56ab-78ab-zzzzzzzzz	Find it on the Azure portal (e.g. here)
APIMAADRegisteredAppClientId	999abce-7777-abcd-a6c9-zzzzzzzzzzz	The Application (client) id of the Entra ID app registration representing your Azure API Management instance.
APIMUserAssignedManagedIdentityId	7777abce-7777-abcd-a6c9-zzzzzzzzzzz	Client ID of user-assigned managed identity of APIM instance
AADSAPResource	https://a4h100	The provider’s name from your NetWeaver SAML setup. Typically, a URL with SID followed Client number
sap-oauth-client-username	ODATAOAUTH	User name provided on SOAUTH2 transaction (/sap/bc/webdynpro/sap/oauth2_config?sap-client=100) Create a named user on SU01 with minimum rights (S_SCOPE, S_SERVICE) and reference that on SOAUTH2. Don’t forget to assign authorized scope.
sap-oauth-client-password	Password for that oauth user	This is only used to request tokens not to authenticate to SAP.
sap-oauth-scope	ZPRODUCTSVIEW_CDS_0001	The scope assigned on SOAUTH2
SAPOAuthRefreshExpiry	86400	Option to set refresh token expiry (default on SAP 2 years). It is not part of the token response.
SAPOAuthServerAdressForTokenEndpoint	a4h-internal.cloudapp.net:44301	Host and port of the target SAP OAuth server. When SAP cloud connector is used, put the virtual hostname and port.

Hints on troubleshooting

There was good feedback on the Postman collection to verify proper SAP Principal Propagation setup. Be aware that the on-behalf-of flow step to request the SAML assertion from Entra involving the managed identity cannot be tested via a REST client from your local device, because only Azure services are trusted for the request.

In general, I would recommend testing the auth flow with the least components involved as possible to reduce problem surface. Meaning, test with a REST client of your choice with client secrets to make sure that your SAP SSO setup and OAuth settings are working. Keep the API Management part and managed identity to after successful initial integration with SAP.

The wider integration context

Q: Does Managed Identity for Azure work only for SAP on Azure?

A: No, using Azure API Managment self-hosted Gateway you can bring that capability any-premises. Besides deploying the gateway directly into your local network, consider also Azure public cloud routing options (ExpressRoute, NVAs, VPN, etc.)

Q: SAP Cloud Connector already supports Principal Propagation for on-premises. Why would I choose this managed identity approach?

A: SAP Integration Suite using SAP Cloud Connector for instance is a prime choice - well established and mature. Nothing wrong with that. Still the credentials need to be managed. You may consider a hybrid where Integration Suite realizes connectivity, while Managed Identity for Azure provides passwordless token requests. Be aware to avoid configuring Principal Propagation twice (OAuth2SAMLBearer flow vs. the Cloud Connector setting with short-lived x.509 certs)

Thoughts on production readiness

Managed Identities are a well-established platform feature on Azure with large scale adoption across services. Furthermore, it is the recommended way of configuring service to service authentication.

Credentials remain in place for the SAP OAuth server as per its OAuth2 flow capabilities. Halfway there so to say. Luckily, token users have a much lower risk profile than actual users.

Final Words

That’s a wrap 🌯. Today you saw how SAP Principal Propagation goes secret-less on Microsoft Entra ID — no passwords, and no certificates. Entra ID with Managed Identity handles it all, mapping Microsoft identities to SAP users while keeping your authorizations intact.

This is what native, secure integration should look like.

👉If you’re still managing credentials manually in 2025, it’s time for an upgrade. It only gets worse from here: Certificate authorities agreed to reduce lifespan to 47 days in stages over the next 1-3 years.

Cheers Martin

SAP LeanIX integrating Microsoft Defender for Cloud Apps

2025-05-06T10:33:38.725000+02:00

When Enterprise Architects and IT Security Speak the Same Language

This blog was co-authored by @Michelle10 (PM @ SAP LeanIX)

Dear community,

In most enterprises, IT security and enterprise architecture are two critical disciplines, each with their own priorities, tools, and perspectives. One is laser-focused on threat detection, compliance, and access control. The other is mapping capabilities, rationalizing applications, and shaping long-term IT strategy.

What happens when these personas complement each other – not just in theory, but in tooling?

That’s exactly where the integration between SAP LeanIX and Microsoft Defender for Cloud Apps comes in.

But wait, what about my managed apps governed by my corporate identity provider? No worries, SAP LeanIX may be integrated with Microsoft Entra ID for discovery and keeping track which apps have SSO etc. as well.

Connecting Two Worlds

Microsoft Defender for Cloud Apps is your frontline for SaaS security and governance to detect threat attacks that arise from your SaaS app interactions and reduce the exposure to such attacks. Furthermore, it helps security teams uncover shadow IT, assess risk, and monitor data flows across

SAP LeanIX, meanwhile, gives enterprise architects the visibility they need to manage complexity – mapping applications to business capabilities, tracking lifecycle data, and supporting IT transformation.

The magic happens when you combine them.

From Discovery to Decision-Making

With this integration, you can pull application usage and risk data from Defender for Cloud Apps directly into SAP LeanIX. That means:

Security teams discover new or risky SaaS apps…

…Architects contextualize those apps within business functions and processes.

You’re no longer just identifying what’s out there - you’re aligning it with your architecture strategy. This turns ad-hoc discovery into intentional governance.

Business Outcomes

Eliminate shadow IT with traceable business context.
Support rationalization with usage-driven decisions.
Align security and strategy with shared data and mutual visibility.

Why It Matters

This integration fosters collaboration between two personas that often operate in parallel but rarely intersect. With Microsoft Defender for Cloud Apps and SAP LeanIX, they do - bringing security and architecture into a shared conversation around risk, capability, and value.

The result? Better decisions, stronger governance, and a much clearer view of your SaaS landscape. All powered from the Defender and Entra ID APIs. Not too bad, huh?

This is how modern IT operates: cross-functional, data-driven, and strategically aligned.

Get Started

Anyone curious about uncovering shadow IT and making better SaaS app decisions? Just reach out to me and Michelle or leave a comment.

Cheers

Martin & Michelle

______________

References:

Re: SAP Principal Propagation without Secrets: How Managed Identity in APIM Simplifies Everything

2025-05-06T13:32:27.628000+02:00

@vbalko-claimate good question. Added a small Q/A section on that.

Re: Integrating low code solutions with Microsoft using SAP Integration Suite has never been easier!

2025-05-07T13:15:39.896000+02:00

@JorgeCalderon the jwt token from caller is part of the standard Authorization header. The sender in my scenario was the SAP OData connector in PowerAutomate. Cheers Martin