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.
- Inasmuch, an OAuth client is an authorization broker (the authentication having been carried away via the saml bearer assertion issuance). Please remember you need grant access to resources to both the OAuth client (via the scopes and the services catalog objects) and to the business user by assigning the required business roles.
- On the other hand, with SAML2BearerAssertion, all you need to care about is the business user and the business roles assignment(s). The access to resource(s) the business user has been granted access to (via business roles assignment) is gained by passing the user’s identity (with saml assertion) directly in the authorization header of S4HC business API call.
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 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…
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.
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.
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:
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 destination service or the APManagement to generate the saml assertion and then call into the API remotely.
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 recipient of the assertion regardless of how many ODATA endpoints are there. And with OAuth you can ask for a bearer access token for multiple scopes. With SAML Bearer Assertion there will be one distinct recipient, what means one saml assertion per each ODATA API call…
Overall, SAMLBearerAssertion may remove a lot of complexity with 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.
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://my301481-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MATERIAL_DOCUMENT_SRV"
I created the saml assertion with a standard SSO policy tailored to my needs as follows:
|An example: GET /A_MaterialDocumentHeader
For reference: here goes a decoded saml bearer assertion:
<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">email@example.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>