26

SAMLBearerAssertion authentication with S/4HANA and S/4HANA Cloud.

 2 years ago
source link: https://blogs.sap.com/2021/06/23/samlbearerassertion-authentication-with-s-4hana-and-s-4hana-cloud./
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Technical Articles
Posted on June 23, 2021 7 minute read

SAMLBearerAssertion authentication with S/4HANA and S/4HANA Cloud.

0 Likes 18 Views 0 Comments

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

274115_274115_l_srgb_s_gl-2-scaled.jpg288201_Resolution_1_R_blue.png

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…

Putting it all together

S/4HANA Cloud.

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:

Picture10-2.png

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:

Picture9-4.png

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.

Picture8-7.png

S/4HANA.

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://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:

request.header.Authorization:SAML2.0 PHNhbWwyOkFzc2VydGlvbiB4bWxuczpzYW1sMj0idXJuOm9hc2lzOm5h...
An example: GET /A_MaterialDocumentHeader

Picture13-6.png

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">[email protected]</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>

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK