- SAP Managed Tags
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.
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:
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 | 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 | 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
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
