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!
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.
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.
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.
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.
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.
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:
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.
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. 😏
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.
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.
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.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 |