SAP Community - Martin Pankraz

Re: Provision users from Microsoft Azure AD to SAP Cloud Identity Services - Identity Authentication

2024-04-05T09:27:20.407000+02:00

not sure what your requirements are. If you need to synch groups you require SAP IPS. The mechanism described on our docs before is about mapping based on attributes like groups but actually re-creating them on the SAP side.

In general, like with any integration project, less redundancy and a single source of truth is beneficial.

KR Martin

Re: Single Sign On to SAP Cloud Integration (CPI runtime) from an external Identity Provider

2024-04-11T08:59:38.676000+02:00

Thank you for sharing @vinayak_adkoli! I am curious what scenarios require a people-based interactive authentication flow for CPI. Shouldn't this be solved on app layer rather than the iflow? SAP Principal Propagation would then be achieved through token exchange on CPI level.

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

2024-04-16T17:06:26.850000+02:00

👉🏿back to Microsoft Learn or jump to GitHub repos🧑🏽‍💻

Dear community,

Printing from SAP is rarely discussed with all the SAP S/4HANA cloud migration chatter, AI bliss, and sustainability efforts to avoid printing at all (don’t print this blog post😈). For some of you it is similarly mission critical, nevertheless.

For instance, consider a manufacturer that needs to print and attach labels to their products before they leave the factory. In case of disruption delivery is halted! It can be equally bad as an ERP outage.

Printer management and driver software maintenance for the different vendors are among the causes of headaches. Anyone emotionally attached to print servers💖? I hope not…

Those days are gone now – you will see the future with cloud printing and Microsoft Universal Print today! No more print servers!

Crowd🎉: Yes, and no more laser cartridge changes or replenishing paper stacks!

Don’t be ridiculous! Of course, you will still change cartridges and replenish paper! Till the robots come at least.

However, the drivers, print servers, and complicated setups are gone 😊And yes, it works with RISE, GROW, Azure, other hyperscalers, on-premises, and even down in your dark cellar where the poor “Raspberry Pies” are ticking away legacy integrat📱 if they have Internet uplink.

Enabling your SAP Business Users (Frontend Printing)

SAP front-end printing sends an output to a printer available for the user on their front-end device. In other words, a printer accessible by the operating system. The same client computer runs SAP GUI, or a browser (Fiori, BTP apps, WebGUI, you name it). To use Universal Print, you need to have access to such printers.

Client OS with support for Universal Print
Add Universal Print printer to your Windows client
Able to print on Universal Print printer from OS

See the Universal Print documentation for details on these prerequisites.

Find more details on the overall setup for SAP on the dedicated Microsoft Learn page.

Enabling unattended SAP processes (Backend Printing)

SAP offers the standard OData service as “Print Queue Item - Read (A2X)” to enable 3rd party integration with SAP Print Queues. You will see the term: Output Management Systems (OMS) being referenced on other SAP sources and docs entries.

In collaboration with SAP SE the capabilities of the communication scenario SAP_COM_0466 “Printing - Pull Integration” were made available to SAP NetWeaver SAP_BASIS releases 757 and upwards. Have a look at the SAP docs to which ERP releases the components apply 😊At the time of publishing this blog that would be S/4HANA 2022 and upwards.

See the SAP note “3420465 – Print queues in on-premise systems” to learn more about how to enable on your own SAP system.

Given the above preparations you are ready to integrate the SAP print queues with the Microsoft Graph API that powers Microsoft Universal Print. To get you started we shipped an open-source project on GitHub. For ease of use, and CI/CD best practices, the app is terraform enabled. But of course, you could also deploy manually if needed.

fig.1 Architecture Overview

Kick-off your SAP backend print process however you prefer with SAP standard means (print function on SAPGUI screens, Spool requests etc.). The simplest means for an integration test would be printing the ALV screen from transaction SP02. Find the print button and choose your new print queue as Output Device.

fig.2 Screenshot of test print from SAP transaction SP02

Note on the side: The new output device of type “Q: print via print queue” can be maintained from transaction SPAD. Find the setting under “Access Method -> Host Spool Access Method”.

On SAP S/4HANA Cloud Public Edition tenants that ship Fiori apps or don’t offer SAPGUI access anymore use the app “Maintain Print Queues” and trigger “Create Test Page

fig.3 Screenshot of Fiori app "Print Queue" to trigger test page print

Our function app on Azure takes care of pulling the SAP print queue items, mapping the queues to your targeted Microsoft Universal Print cloud printer, securely managing the required credentials + identities, and handling robust upload of the print queue items to the cloud.
Once your output device reports back to Universal Print, the app notifies the SAP print queue on NetWeaver about a successful print via OData again. This way the integration and status tracking work end-to-end.

As a result, you will be greeted with a physical hard copy of a test page like this:

fig.4 Screenshot of printed test page

Depending on your needs, the Azure services can be injected into isolated private virtual networks next to the SAP system for instance. Use Azure ARC to deploy on-premises or to other hyperscalers.

Not too bad, huh? 😎

Find the latest deployment instructions, SAP specific FAQ, and community discussion on our GitHub repos. Your contributions are more than welcome!

For general FAQ on Universal Print see Microsoft Learn. In case you are looking to integrate special label printers have a look here.

Thoughts on production readiness

Most print device manufacturers already support Microsoft Universal Print. If they don’t yet, check Microsoft’s Universal Print connector to make them compatible.

Looking for front end printing for SAP on MacOS? Here you go.

Availability from SAP NetWeaver SAP_BASIS releases 757 and upwards ensures decent coverage for more recent SAP ECC and S/4HANA installations 😊

Universal Print relies on the Microsoft Graph API and the components involved in the integration use Azure PaaS services that power various mission critical workloads like O365 and M365 worldwide.

See the latest info on SLA here.

You are all set for prime time with cloud printing with SAP🚀

Partner solutions

SAP and Microsoft partners offer packaged solutions or even managed service offerings for SAP printing. See below initial list to get started.

DOM-Zone from BLUE-ZONE
RISE ONE from All for One Group
Universal Print integration with SAP using SAP Cloud Integration from Kangoolutions

By no means is the list complete. Anyone else looking to be listed or referenced, please leave a comment, or contact me directly.

Final Words

That’s a wrap 🌯you saw today how you can simplify your printing from SAP, reduce the device management overhead, and get rid of the need for print drivers.

Cloud printing for SAP with Microsoft Universal print is applicable to your SAP Business Users (called frontend printing) from their own devices and browsers just as they are used to.

For your SAP backend jobs and SAP’s standard OData API a community-driven open-source integration component is offered on GitHub. Check the Azure marketplace, SAP store, and partner repositories for updates on partner offerings. Above list of partner solutions could get you started.

Let us know what you think and feel encouraged to participate in the community effort🙌.

Partners are welcome to reach out to build a marketplace or managed offering.

Last but not least: thank you to @timo_straub1 and amazing team for the great collaboration🙏

Cheers

Devansh and Martin

Govern SAP APIs living in various API Management gateways in a single place with Azure API Center

2024-04-26T12:33:48.591000+02:00

Find the GitHub repos associated with this post on Azure API Center here.

Our engineering friends from SAP Integration Suite– in particular @Chaim_Bendelac – published a nice “sister blog” on supporting Azure API Management with the API Management capability of SAP Integration Suite here.

Dear community,

Many of you are heavily invested in APIs regarding your SAP ecosystem and the rest of your IT real estate. Given the integration specialization in the SAP space companies decide to use more than one integration tool to cater for SAP and non-SAP integrations. Gartner even says that 75% will use at least two different ones. For many of you that means SAP Integration Suite plus one for non-SAP.

Due to the fast-paced growth of APIs within organizations, inventory, governance, security, and management cannot keep up. The resulting fragmentation and inconsistency lead to adoption challenges, project delays, and security risks. Postman’s State of APIs report 2023 shows that API security incidents happen frequently.

These challenges are summed up under the term “API Sprawl” by the industry. Beware the API sprawl monster is upon you!

fig.1 Illustration of API Sprawl challenge

Key to survival is automatic discovery of available APIs and a single place to enforce guidelines from, or at least know these unmanaged APIs exist in your estate. Forgotten APIs are low hanging fruit for attackers. To drive home that argument: “Improper Inventory Management” made the OWASP top 10 list for API Security in 2023.

Besides that on the human side of things: Which developer likes to develop duplicate functionality just because of the lack of shared API inventory to discover existing stuff?

The API Sprawl monster🦖 much hungry! “Nomnom nomnom more food, yes more food!”.

Azure API Center embarked on the journey of taming the monster.

What API solutions can be registered to Azure API Center?

Azure API Center applies to any API and any API management solution out there. Always remember that API Center is not an API Gateway! It doesn’t expose the endpoints or apply policies to them. That stays with the API Management provider. API Center makes them discoverable and allows decorating APIs with additional info to improve governance.

Let that sink in.

My colleagues are building integrated experiences for the most interesting API and integration tool providers. However, API-based registration in API Center will always be possible.

Get it? APIs to register APIs to register APIs ... yah maybe to complicated for a joke.

fig.2 Azure API Center solution coverage overview

The focus of this blog post will be on inventorying APIs hosted by the API Management capability of SAP Integration Suite to mitigate SAP API sprawl. However, the approach described is applicable to all the other SAP APIs out there hosted on SAP Gateway, SAP Graph, SAP CAP, SAP RAP, CloudFoundry, Kyma, etc. too.

Another prominent SAP service would be SAP Cloud Integration (formerly CPI – Cloud Platform Integration). Many of you expose APIs internally or to business partners through SAP integration flows without fronting them with an API Management solution – you know who you are 😉. Those can be registered too. Unfortunately, there is no built-in option to retrieve the definition of such an endpoint. You may generate an API definition for your http trigger using payload samples for instance. I found this repo useful to get an overview on how to generate OpenAPI definitions from JSON payloads.

Even if you don’t, putting the available metadata on the Azure API Center inventory still improves discoverability and enterprise-wide governance by magnitudes.

But now on to SAP API Management.

Automagically registering SAP API Management APIs on Azure API Center

Our starting point is the SAP BTP service apimanagement-devportal. Check SAP’s docs on the setup process here. Make sure you don’t mistakenly choose apimanagement-apiportal.

The API “API Business Hub Enterprise - Discovery Service (CF)” enables querying all available APIs hosted on SAP API Management on that subaccount. It holds info about their OpenAPI definitions.

Authenticate on the service with any of the supported authentication mechanisms. I chose OAuth2 client credentials grant (instance secret – without payload).

See below response from “/apidiscovery/v1/apis” from my SAP BTP sandbox environment. Pay attention to the attributes of “apiDefinitions” and values for “oas-json”.

{
"@odata.context": "$metadata#apis",
  "value": [
    {
      "name": "GWSAMPLE_BASIC",
      "title": "GWSAMPLE_BASIC",
      "version": "1",
      "lastUpdated": "2024-01-24",
      "releaseStatus": "PUBLIC",
      "protocol": "ODATAV2",
      "entryPoints": [
        {
          "name": "GWSAMPLE_BASIC",
          "type": "PROD",
          "url": "https://msftapim.test.apimanagement.eu10.hana.ondemand.com:443/GWSAMPLE_BASIC"
        }
      ],
      "apiDefinitions": [
        {
          "type": "oas-json",
          "url": "https://eu10devportal.cfapps.eu10.hana.ondemand.com/odata/1.0/data.svc/APIMgmt.APIResourceDocumentations('2797A5F5-E18A-4FCC-826A-C833845303F5')/content/$value"
        },
        {
          "type": "edmx",
          "url": "https://msftapim.test.apimanagement.eu10.hana.ondemand.com:443/GWSAMPLE_BASIC/$metadata"
        }
      ]
}

For your convenience we have provided a sample repo that runs Infrastructure-as-Code scripting to register the SAP APIs using their OpenAPI definitions as highlighted above. On each SAP API definition we execute registration requests on Azure API Center.

You may also use Postman, or SAP Build Process Automation etc. to execute the REST API calls if you prefer. Find our collection here.

fig.3 Flow of automated API registration in Azure API Center

Discover all your APIs where you code – see VS Code and GitHub Copilot in action

We developers like to stay within our flow. So, having the API inventory available at my fingertips in VSCode is a good step into that direction. Also generating http requests to poke around the service and API clients is nice 😎Kiota supports a multitude of languages for SDK generation.

To get that going install the Azure API Center portal VSCode extension.

fig.4 Screenshot of VSCode extension with example OpenAPI definition

Please note that the authorize button (and respective authentication scheme) on the OpenAPI definition explorer is only available if present on the definition file. It looks like this for Basic Auth:

fig.5 Screenshot of auth definition in example OpenAPI spec for SAP OData service

When using the http file and the REST client extension of your choice, you may simply provide the authentication header with Bearer token etc.

Next to the Azure API Center extension view before, you can also use GitHub Copilot Chat to query available APIs from API Center. See Microsoft Learn for more samples. You may search for APIs by key words like so:

@apicenter /search business-partner

Cherry on the cake 🍰is the API Center portal for the classic developer portal experience across your whole registered API inventory wherever that is.

fig.6 Screenshot of Azure API Center portal API inventory view

So far so good on registering APIs and working off the info their definitions provide. But how about governance? I know how desperately everyone wants to plaster cost centers, line-of-business info, and security labels on your interfaces. 😏

Enforced API metadata is your second line of defense against API sprawl

In addition to simply registering APIs you may add custom properties to the object on Azure API Center. So, even if the info is not present on the API itself you can still govern it from Azure. See below sample that I created from the Microsoft Learn tutorial.

fig.7 Screenshot of Azure API Center metadata maintenance view

Knowing which APIs are public facing is useful, isn’t it?

For everyone looking for more sophisticated security with less human error surface, have a look at Defender for APIs. I like the alert rule for “un-authenticated APIs” and disabling endpoints that were not used in the past 60 days most – wait what? Those exist out there in the wild west of SAP on the Internet? 😲See the open-source automatic remediations repos here to mitigate for Azure API Management.

Defender for API integration with 42Crunch brings API security testing and hardening to your CI/CD pipeline.

API Linting gets you to the next level

OK, now let’s look at API style guide compliance. Is everyone playing by your rules? How do you make sure developers notice violations already during design phase rather than at later stages of deployment, release, or even months after the fact when audited?

Good automatic API linting creates much less hassle for everyone in the long run, less cost to fix API definitions after the fact, improved security posture, and a more rewarding experience for the people involved. See below video on the setup of the linting function for OpenAPI using Spectral linting engine.

Anyone aware of a great OData linter and would be curious to explore? Please share!

Get more details on API Linting for Azure API Center from this Microsoft Learn article.

Thoughts on production readiness

Azure API Center is in public preview but due for General Availability with the next wave of announcements, so completely ready for prime time. The same is true for the VS Code extensions and APIs used to orchestrate the integration between SAP API Management and Azure.

Intentionally registering APIs from SAP to Azure API Center improves API inventory management by magnitudes. However, shadow inventory thrives in places you don’t actively look. To mitigate even more effectively the team is building automated discovery from your GitHub org, Azure DevOps, and other popular sources.

SAP Fiori tools on VSCode provided by SAP SE enable usage of the approach described in this blog out of the box. The same is true for SAP CAP development in VSCode.

Final words

That’s a wrap🌯. You saw today how you can effectively counter API sprawl and its negative side effects that put your APIs and organizations at risk. A primary means to achieve that is creating a central API inventory hosted on all the different API Management solutions out there with Azure API Center.

This blog showed how to achieve that using the API Management capability of SAP Integration Suite as an example.

Furthermore, you learned about steps to improve API governance with custom properties and API linting. Eventually, you understood the difference between Azure API Center and an API Gateway.

Find the GitHub repos associated with this post here. It gets you started in no time.

Big #Kudos to Pascal van der Heiden – my brother in crime on this effort. And of course, last but not least to @UdoPaltzer and @vinayak_adkoli for the great collaboration! 🙌

Anyone curious to tap their toe into the waters where the API sprawl monster 🦖 lives, just reach out to me and Chaim or leave a comment.

Cheers

Martin

Re: Govern SAP APIs living in various API Management gateways in a single place with Azure API Cente

2024-05-14T14:52:23.677000+02:00

@saurabhkumbhare API Center went GA on the 6th of May: https://azure.microsoft.com/en-us/updates/general-availability-azure-api-center/

Re: Steps to access Azure Blob Storage via REST API from SAP CPI using Azure Storage Adapter and SAP

2024-05-22T09:11:36.362000+02:00

Hi @Shemy,

What is the reason you want to use http instead of AzureStorage adapter?

The blog above also described the needed parts for http. Find the official API reference here.

KR Martin

Re: Authenticating an API using SAML assertion in SAP API...

2024-05-29T08:08:44.612000+02:00

Hi @giridhar_vegi,

when generating the SAML assertion yourself in APIM you are essentially declaring it your identity provider. That is a severe security risk. Any error or exploitable gap would to lead to user compromise. Identity Providers are purpose-built for this. I am assuming you are bypassing another challenge by looking to implement this yourself. Feel free to share more, so the community can advise on solving the underlying challenge.

If you must explore further have a look at this javascript library and this ApiGee article how to generate your own in SAP APIM. Make sure to lock down access tightly. Either way, I highly discourage this.

KR Martin

Re: SAP AI Core Azure Blob storage SAS token RESPONSE 403...

2024-06-05T10:03:45.189000+02:00

Hi @thomasweckerbasf,

sounds like encoding challenges. Encountered this in the CPI http adapter before. Have a look at this note https://me.sap.com/notes/0003131448 to resolve with triple encoding .

KR Martin

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 integration package is required.

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,
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 and find the updated Microsoft docs 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.

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.
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