OAuth2SAMLBearerAssertion Flow with SAP BTP Destination Service. SAP Analytics Cloud CF edition.

[quovadis]

SAP Analytics Cloud App Integration.

This instalment belongs to a mini series of blogs on SAP Analytics Cloud App Integration with OAuth2SAMLBearerAssertion flow.

 

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

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

Good to know:

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


• Using SAML Assertions as Authorization Grants is covered in here

Putting it all together.

Assuming you have the right level of access to your target SAC system you may need to create your own OAuth2.0 client application. Your SAC system maybe either Enterprise or Embedded Edition tenant on SAP BTP Cloud Foundry.

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.

Let's call the OAuth client Quovadis-SAC. (But this can be any name.)

The OAuth client should be for the interactive usage and there is no need to define any redirect uri. With the saml bearer assertion flow (as apposed to the authorization code flow) there will be no refresh token. We shall only be retrieving a short lived access token.

 

One piece of information you will need from the Destination service from the SAP BTP sub-account level is the public key (=the X.509 certificate) to that you will need to insert into SAP Analytics Cloud tenant's Trusted Identity Provider as depicted below:

 

 

Good to know:

• Each SAC CF tenant is tied up to its own SAP BTP Cloud Foundry sub-account. However, you can only get a partial access to the sub-account for the data acquisition, tunnelling or scheduling workflows via SAP Cloud Connector.


• When you create an OAuth client application from SAC GUI this triggers a creation of an instance of the SAC-dedicated xsuaa service.


• When you add a Trusted Identity Provider that triggers creation of an IDP for the sub-account. The provider name of the Trusted Identity Provider must not be random. It is equal to the CN name of the X.509 certificate.

 

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.<region>.hana.ondemand.com/destination-configuration/v1/sub...



{

  "Name": "Quovadis-SAC",

  "Type": "HTTP",

  "URL": "<SAC tenant URL>",

  "Authentication": "OAuth2SAMLBearerAssertion",

  "ProxyType": "Internet",

  "tokenServiceURLType": "Dedicated",

  "audience": "<OAuth2SAML Audience from SAC/System/Administration/App Integration>",

  "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession",

  "clientKey": "<client_id from your SAC OAuth2 client>",

  "tokenServiceUser": "<client_id from your SAC OAuth2 client>",

  "SystemUser": "<technical user email address>",

  "tokenServiceURL": "<OAuth2SAML Token URL from SAC/System/Administration/App Integration>",

  "tokenServicePassword": "<client_secret from your SAC OAuth2 client>"

}

 

Most of the values in the above destination defintion:

{

  "URL": "<SAC tenant URL>",

  "audience": "<OAuth2SAML Audience from SAC/System/Administration/App Integration>",

  "clientKey": "<client_id from your SAC OAuth2 client>",

  "tokenServiceUser": "<client_id from your SAC OAuth2 client>",

  "SystemUser": "<technical user email address>",

  "tokenServiceURL": "<OAuth2SAML Token URL from SAC/System/Administration/App Integration>",

  "tokenServicePassword": "<client_secret from your SAC OAuth2 client>"

}



will have come from the SAC/CF OAUTH2.0 service endpoints

exposed in SAC/System/Administration/App Integration of your 

SAC CF tenant.

The destination service will eventually call the tokenServiceURL on your behalf

to get you the bearer access token (a jwt token) which in turn you can use with

SAP Analytics Cloud APIs to gain access to SAC tenant assets and resources



For the sake of simplicity let's use a technical user, a user 

that must exist in both the client application and the target 

backend system.



In a productive scenario you would rather be using 

a user JWT token instead!

 

Find destination API call:



https://destination-configuration.cfapps.<region>.hana.ondemand.com/

destination-configuration/v1/destinations/Quovadis-SAC

 

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

• Step 1. create a destination


• Step2. get the destination


• Step3. find the destination


• Step4. use the bearer access token from previous step with any eligible SAC APIs

Good to know:

• You can call the find API any time you need the bearer access token.


• The Destination Service takes care of caching, rotating and renewing of the access token.


• That hugely simplifies the access token housekeeping and also makes the code of the client application very simple.


• All the sensitive information like the endpoints of the SAC OAuth2.0 server as well as the SAC OAuth client application details are never disclosed and are maintained securely.


• Same applies to the private key of the X.509 certificate. It is never disclosed.

 

 

__________

 

Additional resources

 

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