SAP Cloud Integration version 2.44.x comes with support of Principal Propagation to other applications running on SAP Business Technology Platform (BTP) Neo version. This blog explains on how to make use of this enhancement.
Note: Similar feature enhancement of principal propagation to an application running on SAP BTP Cloud Foundry version is in progress. A similar blog will be shared once the feature is available.
Feature per se, is very easy to consume with the HTTP receiver adapter/connector but understanding the required setup of Custom Identity Provider (IdP) and establishing trust between SAP BTP (Neo) accounts, is little complex and time consuming.
The feature shall be explained with a sample use case as depicted in below diagram.
myApp needs to collect the response from an app httpApp, which exposes an HTTP endpoint and is running on SAP BTP Neo version, by making use of an Integration Flow designed and deployed with SAP Cloud Integration.The need is to collect the response of httpApp with the user who logged-in to myApp. That means, the logged-on user’s context (principal) must be propagated from myApp to Integration Flow and then to httpApp. This has been achieved via OAuth2 SAML Bearer Assertion authentication in HTTP receiver adapter/connector.
A similar feature has been enabled for SuccessFactors OData V2 and details are available in the blog https://blogs.sap.com/2018/07/30/sap-cloud-platform-integration-principal-propagation-with-successfactors-odata-v2/ and is recommended to you to go through the above mentioned blog where in most of the setup information has been provided which is also required here, excluding SuccessFactors related setup (e.g. section 1.1.1, 1.6 of the above blog are not relevant here). In this blog, summary of the setup shall be provided.
For the above-mentioned sample use case, you need to complete the setup of user, group creation in the Custom IDP (Cust. IdP); linking Cust. IdP to SubAccnt1; OAuth2 client creation in SubAccnt2 by following the setup guidelines of above mentioned blog as in the section 1.1, 1.2, 1.3 and 1.5. Section 1.1.1 and 1.6 are not relevant here. Follow the section 1.4 of the above-mentioned blog for the trust setup between SubAccnt1 and SubAccnt2. Repeat the same steps to establish trust between SubAccnt2 and SubAccnt3. Follow the section 1.5 for create OAuth2 client in account SubAccnt3.
2. Integration Flow Design and Deployment
Now, we will design the integration flow which talks to an HTTP endpoint exposed by httpApp with OAuth2 SAML Bearer Assertion authentication in HTTP receiver adapter. We will start with deployment of OAuth2 credentials for SAML bearer assertion.
2.1 Credentials Deployment
Follow the section 2.1 of above mentoned-blog till the opening of deployment dialog (step 7). After that, you need to select the Target System Type as SAP Cloud Platform.
- Name: Name of your choice (e.g. myOauthSamlCred), this shall be used as alias name for whole of this security artifact. This name must be provided under the Credential Namein HTTP receiver adapter/ connector properties inside the integration flow.
- Description: Any description of your choice
- Audience: You need to provide the Local Service Provider name of the SubAccnt3 trust management. If the Trust Management’s Local Service Provider Configuration Type is Default, then you need to provide the default URL like https://sap.hana.ondemand.com
- Client Key: The OAuth2 client id created in SubAccnt3 (where httpApp is running)
- Token Service Url: The token service URL of SubAccnt3
- Target System Type: SAP Cloud Platform.
- Token Service User: The OAuth2 client id created in SubAccnt3
- Token Service Password: The OAuth2 client secrete created in SubAccnt3
- Additional Properties: The deploy dialog window already captures the additional properties required for the complete use case. Let the default values as is.
2.2 Integration Flow Design
In the Design space of your SAP Cloud Integration Web UI, create or choose a package of your choice. Create integration flow artifact. (Steps to create integration flow project are omitted).
Consider the sample integration flow created
In HTTP receiver adapter/connector, in the Address field, provide the HTTP endpoint exposed by the httpApp. Observe the Authentication type to be OAuth2 SAML Bearer Assertion. For the credential name, provide the name you have used while deploying the OAuth2 SAML credentials (e.g. myOauthSamlCred as mentioned in section 2.1 and step 1 above).
Save and deploy the integration flow. Since it has SOAP sender adapter, it shall result in the SOAP endpoint URL in SAP Cloud Integration. To get the SOAP endpoint URL, go to monitoring of your Web UI and then in, Manage Integration Content ->click on Started tile. Copy the SOAP endpoint URL keep it in temporarily in a text editor. This shall be used in destination configuration created for myApp.
3. Destination Configuration for myApp
Follow the steps of section 3 of the above-mentioned blog to setup a destination which will be used for the communication between myApp and Integration Flow. After this step, when you invoke the myApp, the login screen will be of custom idp what you have configured. After successful log-in, the myApp will invoke the integration flow via destination configuration and integration flow will invoke endpoint exposed by httpApp via HTTP receiver adapter with user context/principal being propagated to all the involved applications across different accounts.
With OAuth2 SAML Bearer Assertion authentication type in HTTP receiver adapter/connector, you can achieve the principal propagation to the application(s), running on SAP BTP Neo version, with will little complex infrastructure setup steps :).