Foreword.

This instalment belongs to a mini series of blogs on the OAuth2SAMLBearerAssertion Flow with the SAP BTP Destination Service. Happy reading!

Abstract.

The SAML 2.0 Bearer Assertion Flow typically comes into play when we want to give a client application’s users an automated access to remote resources or assets which are protected with the OAuth2.0 protocol.

A common assumption is that the user’s remote resource access scope will be determined by the user’s identity as it is known on the client application side.

Thus the most important aspect of this flow is the propagation of the user’s identity to the backend system commonly referred to as Principal (=user identity) Propagation

Good to know:

• Please consider there are other types of authorization flows that might be a better fit for your application.

User propagation (SSO) with the OAuth2SAMLBearerAssertion Flow.

Using SAML Assertions as Authorization Grants covered in here

And this is where the SAP BTP Destination service comes to the rescue.

Putting it all together.

Before you can configure the API hub sandbox environment you will need to have created an instance of the destination service.

Please refer to the following article on the details for the sandbox environment configuration with SAP API Business Hub.

Assuming you have the right level of access to your target SFSF system you may now create there your own OAuth2.0 client application. Let’s call it Quovadis-SFSF.

One piece of information you will need from the Destination service created on SAP BTP sub-account level is the trust’s public key that you will need to insert into the Quovadis-SFSF OAuth2.0 client application as depicted below:

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

All you need to do is create a definition of your destination 
Your destination will be called by the destination 
service find api any time you need to procure a bearer access token
to authorize access to remote resource.

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

Let’s rather do it with the APIs from the sandbox environment as follows:

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

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

{
    "Name": "Quovadis-SFSF",
    "Type": "HTTP",
    "URL": "https://apisalesdemo2.successfactors.eu/odata/v2/User/$metadata",
    "Authentication": "OAuth2SAMLBearerAssertion",
    "ProxyType": "Internet",
    "tokenServiceURLType": "Dedicated",
    "audience": "www.successfactors.com",
    "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession",
    "companyId": "<SFSF company code>,
    "clientKey": "<apiKey from Quovadis-SFSF application>",
    "apiKey": "<apiKey from Quovadis-SFSF application>"
    "SystemUser": "<technical user>",
    "nameIdFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
    "tokenServiceURL": "https://salesdemo.successfactors.eu/oauth/token"
 }

Most of the values will need to come from the OAUTH2.0 service 
which is used to prtect the remote resource you are trying 
to have your user get access to

For the sake of simplicity let's use a technical user, a user 
that must exist in both the client application and the target backed end system.

In a productive scenario you would rather be using a user JWT token instead!

Find destination API call:

https://destination-configuration.cfapps.eu10.hana.ondemand.com/
destination-configuration/v1/destinations/Quovadis-SFSF

As a result of this call you will get the bearer access token that you can use to call into the any SFSF OData APIs, your user may have acces to, as depicted below:

Last but not least. Let’s see the rationale behind using the Destination Service.

best wishes

Browse my community blog posts