SAP Build Process Automation – Use Principal Propagation (SCI/IAS) in Actions sample: CAP Services

[[{“value”:”

This post demonstrates how to connect SAP Build Process Automation (SBPA) to CAP (Node.js) API services using principal propagation. The same approach can also be applied when connecting SAP Integration Suite MCP to CAP (Node.js) API services.

There is an existing published blog SAP Build Process Automation – Use Principal Propa… – SAP Community, demonstrates principal propagation from SBPA (XSUAA) to CAP API Services (XSUAA) using OAuth2SAMLBearerAssertion. 

In contrast, this scenario is showing how SBPA (XSUAA) communicating with CAP API services secured by SAP Cloud Identity Services (SCI/IAS) through OAuth2SAMLBearerAssertion under the same BAIP Subaccount. and reusing the same CAP Services built in the previous article, MCP Server with Integration Suite, expose CAP API … – SAP Community.

Note: 

1. OAuth2JWTBearer does not appear to support the authentication flow from SBPA (XSUAA) to CAP API services secured by SCI/IAS, even when both applications are deployed within the same SAP BAIP subaccount.
2. SCI is referring to SAP Cloud Identity Services

→ SAP Build Process Automation (Authenticated via XSUAA)
→ BTP Destination Service (OAuth2SAMLBearerAssertion)
→ CAP Node.js API Services (executed as the authenticated user)

Pre-requisite:

• SAP BTP with Cloud Foundry Enabled
• SAP Build Process Automation
• SAP Cloud Identity Services (IAS)

1. CAP Services creation and deploy

This writing will reuse the CAP services created on the previous writing. Refer to the blog MCP Server with Integration Suite, expose CAP API … – SAP Community step 1.

2. Establish Trust between BAIP/BTP destination with SAP SCI/IAS

Setup the Subaccount as Corporate Idp in the SAP Cloud Identity Services

Information: SAML Bearer Assertion Flow between Cloud Foundry Applications | SAP Help Portal

Navigate to BAIP → Destination Trust → Export the metadata.xml

Navigate to SAP Cloud Identity Services Admin Console → Identity Providers → Corporate Identity Providers

Upload the Subaccount SAML metadata.xml that downloaded in previous step, the rest of the fields will be auto populated.

Enable Identity Federation

3. Setup Provider App – CAP API Services authentication information

 Ensure the Application has enabled the trust all corporate identity provider or restrict to only the corporate identity provider (subaccount) created in previous step

Always enable the principal propagation in this section. Note: even though this checkbox does not impact anything at this moment, but it is good to enable this in case SAP updated the authentication framework on checking this checkbox.

Ensure the SAML Bearer option is enabled.

Note: This can be either configured in MTA file or directly update in SCI, preferable configure this option in MTA file, as any future deployment will override any manual changes in SCI.

Create a new service key for SBPA and take note of the client id, client secret and url

4. Create BAIP/BTP Destination – OAuth2SAMLBearerAssertion

 Create a destination will be used by SBPA to consume the CAP Services

---

 

5. SBPA Setup and Testing

This demo will not show step by step on action and process creation. You can go through the learning from SAP Learning website.

SBPA Control tower -> Import the created destination 

Create new Action – CAP Bookshop Service – Admin and test with the destination

Can refer to the step 4 on how to extract the API metadata – MCP Server with Integration Suite, expose CAP API … – SAP Community

Create a Process, test create new Author via the API

Choose the desired destination during deployment

Launch the form, enter the information and click Submit

Check the monitoring to confirm the new Author is created with named-user.

6. Alternative option – create separate Cloud Identity Services instance with dependency setup

This approach enables a standalone SAP Cloud Identity Services (SCI/IAS) instance to act as the consumer of the CAP API services.

Cloud Identity Service Instance A (with CAP application bound, without SAML Bearer Authentication enabled)
|– with Dependency setup Cloud Identity
Service Instance B (without CAP application bound, separate client ID B, with SAML Bearer Authentication enabled)
|– Destination setup with client ID B, target CAP API
SAP SBPA calls the CAP services via Destination OAuth2SAMLBearerAssertion

Create a separate Cloud Identity Service instance in BAIP/BTP

• Service: Cloud Identity Services
• Plan: application
• Instance Name: <any>
• Create service key and take note of the client id, client secret and url

{
“authorization”: {
“enabled”: true
},
“display-name”: “SBPAConsumer”,
“oauth2-configuration”: {
“redirect-uris”: [],
“token-policy”: {
“access-token-format”: “jwt”
},
“grant-types”: [
“urn:ietf:params:oauth:grant-type:saml2-bearer”
]
},
“provided-apis”: [
{
“description”: “SBPA Consumer”,
“name”: “SBPA Consumer”
}
],
“xsuaa-cross-consumption”: true
}

Setup the dependency in SCI

• Dependency Name: <any name that will be used in Destination setup later>
• Application: <SCI instance application that have CAP bound>
• API: <SCI instance application API, this is defined in MTA.yaml during CAP deployment>

Goto BTP setup new destination

Test the new destination in SBPA, and confirmed the destination is working and user is propagated.

Reference

• SAML Bearer Assertion Flow between Cloud Foundry Applications | SAP Help Portal
• SAP Build Process Automation – Use Principal Propa… – SAP Community
• MCP Server with Integration Suite, expose CAP API … – SAP Community

“}]] 

  Read More Technology Blog Posts by Members articles 

#abap