This instalment belongs to a mini series of blogs on OAuth2SAMLBearerAssertion Flow leveraging SAP BTP Destination Service with S/4HANA Cloud inbound ODATA services. Bon voyage:)

Set Up Authentication for SAP S/4HANA Cloud Extensions

Putting it all together

Configure OAuth communication with S/4HANA Cloud.

We will follow the sequence of the configuration tasks as described in the official documentation, namely:

Quovadis-S4HC.

Assuming you have the right level of access to your target S4HC system and that you have created a communication user you may now create there your own OAuth2.0 client application (=communication system+communication arrangement).

Let’s call it Quovadis-S4HC.

Last but not least you can create a communication arrangement for a given communication scenario.

The SAML2 Audience is the service provider and is the value
of your S4HC tenant URL.

The Token service URL is the OAuth2.0 IdP endpoint. 
The Destination service will call this endpoint with the saml 
assertion it has generated internally.

You can add the required scope as a Token service URL 
endpoint's query parameter (?scope=<scope>)
or you can pass it in the scope property in the destination 
definition.

Creating a destination.

You can create a destination definition using either GUI of the SAP BTP sub-account or programmatically calling the destination service APIs.

Assuming you will be rehearsing the access to the destination 
service APIs with the SAP Business API Hub sandbox environment
or alternatively using the API Management,
you do not need to write a single line of code.

All you need to do is create a definition of your destination
as demonstrated below.

Then you may call that destination with the destination 
service find api any time you need to procure a bearer access token
to authorize access to remote S4HC resource.

Post (=create) a new destination:
Put (=update) an existing destination:

https://destination-configuration.cfapps.xx99.hana.ondemand.com/destination-configuration/v1/subaccountDestinations

{
  "Name": "Quovadis-S4HC",
  "Type": "HTTP",
  "URL": "https://my999999.s4hana.ondemand.com/sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV",
  "Authentication": "OAuth2SAMLBearerAssertion",
  "ProxyType": "Internet",
  "tokenServiceURLType": "Dedicated",
  "audience": "https://my999999.s4hana.ondemand.com",
  "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:x509",
  "Description": "https://api.sap.com/api/API_PURCHASEORDER_PROCESS_SRV/overview",
  "clientKey": "<client_id>", //==communication user name
  "nameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "scope": "API_PURCHASEORDER_PROCESS_SRV_0001",
  "x_user_token.jwks_uri": "https://<identityzone>.authentication.xx99.hana.ondemand.com/token_keys",
  "tokenServiceUser": "<client_id>", //==communication user name
  "tokenServiceURL": "https://my999999-api.s4hana.ondemand.com/sap/bc/sec/oauth2/token",
  "userIdSource": "email",
  "tokenServicePassword": "<client_secret>" //==communication user password
}

Asserting user’s identity

A user’s identity.That’s the most important part of the setup.

You have a choice between a static technical user, or a dynamic user.

The destination service supports dynamic user indentities via 
a user JWT token. 
You may need to provide an access url to OpenID Connect provider metadata.
Please add in the destination service's x_user_token.jwks_uri property 
the value of the jwks_uri url from the OIDC provider metadata.

As aforementionned, the value of this property must come 
from the OIDC user identity provider metadata.
In case you are using the XSUAA service as the OIDC provider you could call
the .well-known/openid-configuration endpoint of the XSUAA service url,
in order to retrieve the OIDC metadata, for instance:

https://<identityzone>.authentication.xx99.hana.ondemand.com/.well-known/openid-configuration

then you will look for jwks_uri and copy the value of jwks_uri 
(it is yet another url) to the x_user_token.jwks_uri property 
in the destination defintion.

Disclaimer:
In a productive scenario you must be using a user JWT token!
However a technical user may be used in the initial sandboxing 
and concept proving of the entire configuration.

In either case, the user must exist in both the client application 
and the target S4HC system.

Finding destination.Obtaining the bearer access token to call into S4HC business API.

Find destination API call:

https://destination-configuration.cfapps.xx99.hana.ondemand.com/
destination-configuration/v1/destinations/Quovadis-S4HC

Please substitute xx99 by the BTP subaccount region where you
have provisionned the destination service on a subaccount level,
for instance 'eu10' etc.

As a result of this call you will get the bearer access token that you can use to call into S4HC OData API, and retrieve the assets like Purchaser Orders or Sales Orders, your user has been granted access to, for instance:

 "authTokens": [
    {
      "type": "Bearer",
      "value": "-hY-nuoXHtusskpbJBHeC4EX8jPi0jYZ7RAZP9Q7_WadI111",
      "http_header": {
        "key": "Authorization",
        "value": "Bearer -hY-nuoXHtusskpbJBHeC4EX8jPi0jYZ7RAZP9Q7_WadI111"
      },
      "expires_in": "3600",
      "scope": "API_PURCHASEORDER_PROCESS_SRV_0001"
    }
  ]

Conclusion.

__________

Additional resources.