SAP Community - Martin Pankraz

Re: Open your SAP OData APIs for some swagger – or how to make friends with the other kids from the

2024-03-06T09:19:03.466000+01:00

1. Hard for me to tell from afar. You need to have the whole chain that sits on top of your client leaf certificate in C4C available in Azure APIM as CA certificate and the client cert for C4C on the "Certificates" section.

2. No won't work. How about you swap from Consumption to Developer tier? With Azure free credits you will be able to perform your validation at no cost.

KR Martin

Re: IAS is mandatory for customers with Microsoft Azure S...

2024-03-11T07:59:39.888000+01:00

We describe our best practices for the scenarios on the Microsoft docs here: https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/scenario-azure-first-sap-identity-integration

Re: IAS is mandatory for customers with Microsoft Azure S...

2024-03-11T08:01:10.336000+01:00

We describe our best practices for the scenarios of integrating SAP IAS and Entra ID (formerly Azure AD) on the Microsoft docs here: https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/scenario-azure-first-sap-identity-integration

Re: SAP Connector for .NET Framework 5.0 and higher

2024-03-20T16:09:51.541000+01:00

Hi @KentP,

SAP is tracking the item as influencing request. Engineering will make an update to give more clarity on timeline.

KR Martin

Re: Simplify SSO with Microsoft Entra ID (Azure AD) & SAP Identity Authentication Service

2024-03-22T08:56:16.855000+01:00

Thanks for sharing @PolySonika. I'd like to add the reference to the best-practices guide for Entra ID (formerly Azure AD) with SAP IAS. Find it on Microsoft Learn here.

Re: SAP application slow after Microsoft Defender was installed on server

2024-03-27T09:39:05.160000+01:00

@Syamkriz Please have a look at Microsoft's dedicated guidance for Defender for Endpoint on SAP hosts:

https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/mde-linux-deployment-on-sap

https://techcommunity.microsoft.com/t5/running-sap-applications-on-the/microsoft-defender-endpoint-mde-for-sap-applications-on-windows/ba-p/3912268

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

2024-04-02T09:53:38.724000+02:00

Hey @tskwin,

Have a look at the Microsoft learn page for our recommendations on Entra ID with SAP IAS. Note on the side: Be aware SAP recommends SAP IDM customers to migrate to Entra ID. Meaning the already deep integration between both ecosystems will increase even more over time.

KR Martin

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

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

Hey @tskwin,

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.

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

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.

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.