This is a follow-up blog post to previously published How to generate SAML bearer assertion token with SAP BTP Destination Service? When it comes to unattended side by side, system to system or app2app integrations with S/4HANA systems, the choice of an unmanned and password-less authentication method is between OAuth2SAML2BearerAssertion or SAML2BearerAssertion. Good to know:
|
Abstract
 | Both OAuth2SAML2BearerAssertion and SAML2BearerAssertion rely on the saml bearer assertion authentication paradigm for unattended business users' identity propagation. And in either case we can leverage our polyvalent SAP BTP destination service. |
Then, what makes them different is that with OAuth there is the OAuth client which is acting as a resource gatekeeper...It will grant a bearer access token based on the scopes (=services/permissions) that both the OAuth client and the resource owner (=the business user) have been granted access to.
|
That brings the following question: what would be the compelling reason or scenario to use one or the other ? And which one to choose when both are permitted and available for a given API? Both Basic and x509 client certificate authentication methods are user centric (even if the user is a technical user). Thus, they are not really well-suited for unmanned system to system, app2app integration scenarios. And overall there are quite many S4HC APIs that do not natively support OAuth2.0! To that point, the saml bearer assertion authentication method is likely a perfect authentication alternative for all these non-OAuth2.0 enabled S4HC APIs making them usable in unattended side by side integrations. Let's see it in more details... |
Putting it all together
When creating a Communication System in S4HC and aiming at system to system, side by side, password-less integration without user interaction with the APIs there are two password-less authentication choices available as follows: a. OAuth 2.0 Identity Provider. (Communication system). Before you can authenticate with a bearer access token in the authorization header [to be granted access to resources via an OAuth 2.0 client], you have to configure a trusted relationship to the required identity provider (x509 certificate) as depicted below: b. SAML Bearer Assertion Provider. (Communication system. Before you can authenticate with a SAML Assertion in the authorization header, you have to configure a trusted relationship to the required identity provider (x509 certificate) as depicted below: As a result, with the 2nd option it is possible to use the non-OAuth enabled APIs with a saml bearer assertion passed in the authorization header of the business API call. For instance, in the below scenario the API_MATERIAL_DOCUMENT_SRV ODATA API only supports the basic authentication (or x509 client certificate). However, by having configured the SAML Bearer Assertion Provider in the communication system we can use either the BTP's destination service or API Management, as shown in the Appendix section below, to generate a saml assertion and then call into the API remotely.  |
| Please refer to previously published How to generate SAML bearer assertion token with SAP BTP Destination Service? for a discussion around S/4HANA OP and SAP BTP destination service to generate the saml assertion. |
Conclusion.
But what about the OAuth-enabled APIs? What would be the advantage or disadvantage of calling some OAuth-enabled API directly with the saml bearer assertion in the authorization header of the API call over first going to the OAuth client to get a bearer access token and then calling the same API with the access token ? All I can think about for now is that with an OAuth client the OAuth token endpoint is the single and unique recipient of the saml assertion regardless of how many ODATA endpoints are there. And moreover, with OAuth, you can ask for a bearer access token for multiple scopes. With SAML Bearer Assertion there will have to be one distinct recipient per ODATA API what results in one saml assertion per each ODATA API call... Still, SAMLBearerAssertion may remove a lot of complexity when it comes to setting up an unmanned access to resources (especially with S/4HANA on-premise ABAP systems). And SAP help pages are already full of references for instance Integrating SAP Business Application Studio. Looking forward to hearing from you. Please post any questions and comments you may have in the add comment section below. Bon voyage! |
__________
Appendix
Here goes an example of how to execute an ODATA API with the saml assertion in the authorization header using SAP API Management part of SAP Integration Suite.
The target URL in either the destination definition or in APM, namely:
"https://my30xxx-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MATERIAL_DOCUMENT_SRV"
must match the recipient in the saml assertion as follows:
Recipient="https://my30xxxx-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MATERIAL_DOCUMENT_SRV"SAP API ManagementI created the saml assertion with a standard SSO policy tailored to my needs as follows: |
request.header.Authorization:SAML2.0 PHNhbWwyOkFzc2VydGlvbiB4bWxuczpzYW1sMj0idXJuOm9hc2lzOm5h...| An example: GET /A_MaterialDocumentHeader |
For reference: here goes a decoded saml bearer assertion:
<?xml version="1.0"?>
<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="_4ed159487b7f515926c3ced4ae12a4ed" IssueInstant="2021-06-23T20:10:11.752Z" Version="2.0">
<script/>
<saml2:Issuer>quovadis/ateam-isveng</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_4ed159487b7f515926c3ced4ae12a4ed">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="xs"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>b02SWxKczW2o2LyOiTj76c6uNSs=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>nIfK2bPWr8tZpxy6dd/KeEhlnJUKSw9McK1VsK7axUrQQ5+O1grsJFr3SizDk5dvSDiszcxEXp+jL0HGhKQsYe+lxm+rFtKv/ycT/LJ/XfGUYj1HG+R4UiH1/IXAQ3xIXbViolKexlDpUFwj99OsX11EkHTfJoqxYo8mJBQE4xhxx4ppcrx9B+MvGTvA/JHwN4yKcE=</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIFGzCCAwMCBGBb1dwwDQYJKoZIhvcNAQELBQAwUjELMAkGA1UEBhMCVVMxDDAKBgNVBAoMA1NB y2Bie3pZsV0QGgSCMZ8kNQobunEPnfkXysLhUvWzniY0UI9uLY7F9934p3PLnZAJOhLJO0X6cHCF bMC+6GxXTdisQVivIOKUURdaHVX6B270SUDiP6TDPApn9E+IaISzPRpkXT6c0QNVYg37DBU/qhSN</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:Subject>
<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">firstname.lastname@acme.com</saml2:NameID>
<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml2:SubjectConfirmationData NotOnOrAfter="2021-06-24T20:10:11.751Z" Recipient="https://my30xxxx-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MATERIAL_DOCUMENT_SRV"/>
</saml2:SubjectConfirmation>
</saml2:Subject>
<saml2:Conditions NotBefore="2021-06-22T20:10:11.751Z" NotOnOrAfter="2021-06-24T20:10:11.751Z">
<saml2:AudienceRestriction>
<saml2:Audience>https://my30xxxx.s4hana.ondemand.com</saml2:Audience>
</saml2:AudienceRestriction>
</saml2:Conditions>
<saml2:AuthnStatement AuthnInstant="2021-06-23T20:10:11.751Z" SessionNotOnOrAfter="2021-06-24T20:10:11.751Z">
<saml2:AuthnContext>
<saml2:AuthnContextClassRef>urn:none</saml2:AuthnContextClassRef>
</saml2:AuthnContext>
</saml2:AuthnStatement>
<saml2:AttributeStatement>
<saml2:Attribute Name="client_id">
<saml2:AttributeValue xsi:type="xs:string"><Communication user></saml2:AttributeValue>
</saml2:Attribute>
</saml2:AttributeStatement>
</saml2:Assertion>API services summary
To access API services, you need to authenticate yourself. Each API supports different authentication methods.
| Authentication Method | Description |
|---|---|
| Basic | Authentication with a user name and password. |
| x509 | x509 certificates are used in many Internet protocols, including TLS/SSL. An x509 certificate consists of a public key and a private key. The public key contains the identity information, such as a host name, an organization, or an individual. The public/private key pair is used to establish secure communication. |
| OAuth2 | OAuth 2.0 is a widely adopted security protocol for protection of resources over the Internet. It’s used by many social network providers and by corporate networks. OAuth 2.0 allows an application to request authentication on behalf of users with third-party user accounts, without the user having to grant its credentials to the application. |
| Single Sign On using SAML | SAML is an XML-based framework for exchanging authentication and authorization information. An identity provider issues a security token, which enables the authentication at a service provider. |
APIs created by SAP are categorized according to the main purpose of the messages being communicated as follows:
| Service Categories | Description |
|---|---|
| Application-to-Application (A2A) | A2A services facilitate the exchange of business information between different systems to connect business processes within company borders. |
| Application-to-Cross Application (A2X) | A2X services facilitate the exchange of business information between a system and an unspecified client. They’re often used to build user interfaces (UIs) based on the back end, without an intervening communication layer. For this reason, A2X messages contain all the necessary information for understanding the message, such as the code names or texts to be displayed on the UI. |
| Business-to-Business (B2B) | B2B services facilitate the exchange of business documents across companies. |
__________
Additional resources.
- SAP Managed Tags:
5 Comments
