[[{“value”:”
As security requirements continue to grow, many SAP integrations are moving away from traditional Basic Authentication and shifting to stronger approaches such as OAuth 2.0, Mutual TLS (mTLS), and Principal Propagation. These mechanisms help protect communication between on-premises SAP systems and SAP BTP services while also improving trust, traceability, and identity-based access control. Even though the overall setup may look simple in an architecture diagram, building the full end-to-end flow can be complex because several components must be configured correctly and must work together.
In this implementation, the goal was to build a secure connection between an on-premises SAP ABAP system and SAP Cloud Integration (CPI) on SAP BTP without depending on technical users or stored passwords. Instead, the solution uses OAuth-based authentication, certificate trust through mTLS, and Principal Propagation so that the original business user identity can be passed securely across the entire integration flow. To make this work, trust had to be configured carefully across SAP ABAP, CPI, SAP Cloud Connector, and the target backend system.
SAP provides documentation for many of these individual areas, but it is often difficult to find one complete guide that explains the full authentication and identity propagation journey from start to finish. This blog is intended to close that gap by presenting the architecture, the configuration approach, and the main lessons learned during the implementation.
Although this setup was implemented in SAP BTP Neo Cloud Integration, the same overall concept can also be applied to Cloud Foundry and to other SAP BTP services that require secure communication between cloud and on-premises SAP systems.
Architecture Overview
The runtime flow begins in the SAP ABAP system, where the consumer proxy initiates the outbound request using OAuth 2.0 with a SAML 2.0 Bearer assertion. CPI on SAP BTP acts as the receiving side, while the trust configuration and Principal Propagation setup ensure that the originating user identity is preserved across the communication path. As a result, CPI can process the inbound trusted request securely, allowing the end-to-end integration to function without the need for a static technical password.
Prerequisites
- A BTP/CPI subaccount with access to build trust configuration and user authorization.
- An ABAP backend with access to build OAuth 2.0 profile creation and SOAMANAGER.
- Cloud Connector accesses the connect BTP subaccount and set-up principal propagation.
- mTLS trust already established between Cloud connector with ABAP with/without Web-dispatcher in-between.
Step 1. Create the OAuth Client in CPI
The first step is to create the OAuth client configuration in CPI that supports the inbound integration flow originating from the SAP ABAP system. This configuration is required so CPI can receive and process requests secured through OAuth 2.0 with a SAML 2.0 Bearer assertion.
CPI Subaccount -> Security -> OAuth
In the client details, create the OAuth client using the “Client Credentials” option. Generate the “Client ID” and “Client Secret” and store them safely, as they will be required later to establish trust with the back-end ABAP system. For iFlow-based communication, choose the subscription for “iflmap”.
Other details about the authorization server, such as the “Token Service URL” and “Authorization Service URL”, are also available in this section. These details are required later when authenticating the incoming request from the SAP ABAP system. ABAP will use these details to get tokens generated.
Step 2. Create Local Service Provider Settings
After the client is created, the next step is to create the trust setup and prepare CPI to work with different identity providers. In this step, create a custom service provider, as this is required to integrate the external identity provider as the application identity provider that will be configured later. Also make sure to note the “Local Provider Name (URL)”.
CPI Subaccount -> Security -> Trust
Step 3. Configure the ABAP OAuth 2.0 Profile
On the ABAP side, create an OAuth profile in the ABAP Workbench. Below is the standard code snippet used for this setup.
*Access Oauth2.0 client profile configuration
TRY.
CALL METHOD cl_oauth2_client=>create
EXPORTING
i_profile = i_profile
i_configuration = i_config
RECEIVING
ro_oauth2_client = DATA(lo_oauth2_client).
CATCH cx_oa2c INTO lo_oa2c.
es_return = VALUE #( type = lc_e
message = |Unbale to Get OAuth 2.0 Client with | &&
|profile: { i_profile } and Config: { i_config }| ).
RETURN.
ENDTRY.
*Call the below method to access any generated Token within time frame of the the Token Expiry Time((For example: 15 min)
*This method call will be failed every time when the token is expired.
TRY.
CALL METHOD lo_oauth2_client->set_token
EXPORTING
io_http_client = lo_http_client
i_param_kind = i_param_kind.
CATCH cx_oa2c INTO lo_oa2c.
*Call the below method to generate the token in every Token Expiry time (For example: 15 min)
*The token will be internall saved in SAP tables/ICF. To enhance the security, the token would not be accessible out in the code.
TRY.
CALL METHOD lo_oauth2_client->execute_cc_flow.
CATCH cx_oa2c INTO lo_oa2c.
es_return = VALUE #( type = lc_e
message = |Unable to Execute Client Credentials Flow| ).
RETURN.
ENDTRY.
*Call the below method to access any generated Token within time frame of the the Token Expiry Time((For example: 15 min)
*This method call will be successful when method execute_cc_flow call is successfully executed.
TRY.
CALL METHOD lo_oauth2_client->set_token
EXPORTING
io_http_client = lo_http_client
i_param_kind = i_param_kind.
CATCH cx_oa2c INTO lo_oa2c.
es_return = VALUE #( type = lc_e
message = |Unable to Set Access Token in HTTP-Client| ).
RETURN.
ENDTRY.
ENDTRY.
SAP has provided enhancement/BAdI “OA2C_SPECIFICS” to make adjustments in the standard code and configuration settings. A custom BAdI class has to be implemented using the superclass “CL_OA2C_SPECIFICS_ABSTRACT”. The required methods can then be redefined as needed.
Follow the below reference link for more details:
Once the OAuth profile is created, configure it further in ABAP by maintaining all the required settings and details needed for this integration scenario.
Tcode: SOAUTH2_CLIENT
Client ID: Same ID created in Step 1
Client Secret: Same secret created in Step 1
Token Endpoint: Token endpoint of the CPI authorization server from Step 1
Also make sure SAML2 attributes are activated.
SAML2 Audience URL: The CPI custom service provider URL created in Step 2
SAML2 Recipient: The CPI authorization server token URL from Step 1
SAML2 User Mapping Mechanism: Choose email
Once done, make sure you download the SAML2 metadata for ABAP. This will be needed to onboard your ABAP system into CPI.
Step 4. on board your ABAP SAML2 details into CPI
In the next step, create the “Application Identity Provider” for ABAP in CPI. In the previous step, ABAP was configured to recognize CPI as the authorization server, and now CPI must be configured to trust ABAP by establishing the trust relationship between the two systems. Once the “Application Identity Provider” is created in CPI, the system is able to accept and process the SAML 2.0 Bearer assertions issued by the ABAP system during the OAuth flow.
In CPI, add ABAP as your identity provider by clicking “Add Trusted Identity Provider” and uploading the SAML2 metadata downloaded from ABAP.
CPI Subaccount -> Trust -> Application Identity Provider
Make sure to verify the below details.
Single Sign-On URL: You can use your ABAP FQDN as the URL
Single Logout URL: Same as above
Step 5. Map Assertion Attributes and Backend Groups
Once ABAP is established as the identity provider in CPI, make sure the required attributes are created there as well. This ensures that any ABAP attributes carried by the ABAP system while initiating the call can be matched correctly with the CPI configuration.
Proper attribute maintenance is important so that the attributes sent by ABAP are recognized and mapped accordingly during the authentication process. This allows the user information and context received from ABAP to be processed seamlessly throughout the authentication flow.
Click on the newly created ABAP identity provider to edit it. In the same ABAP identity provider, maintain the attributes and group settings as shown below.
Next, create an authorization group in CPI for the user and assign the required permissions so the users assigned to it can perform the necessary activities within CPI. In this step, create a new group with any suitable name, such as “Oauth2_user”, and assign the permissions as shown below.
Once the group is created, the same ABAP calling user needs to be assigned to this group in CPI. This ensures that the user initiating the call from the ABAP system inherits the required permissions and authorizations available through the group within CPI.
CPI Subaccount -> Security -> Authorization -> Groups
Next, make sure the ABAP identity provider uses this group as the default group for authorization, and also create a mapping rule. Ideally, use a wildcard pattern that matches your company domain, such as “.*@yourcompany.com$”.
Again, go back to the ABAP identity provider and open it.
CPI Subaccount -> Security -> Trust -> Application Identity Provider
Step 6. Create the Destination with OAuth2 SAML2 Bearer
Finally, create a destination in CPI. Once the Principal Propagation setting is configured in the CPI sender configuration, this destination is used through the SAP Connectivity service to retrieve and propagate the required user attributes for the outbound call.
CPI Subaccount -> Connectivity -> Destination
URL: Only your provider company FQDN; do not add any path to it. CPI iFlows will use the rest of the URL from the sender channel definition.
Proxy: Internet
Authentication: OAuth2SAMLBearerAssertion
Audience: The URL of your CPI service provider created in Step 2
AuthnContextClassRef: urn:oasis:names:tc:SAML:2.0:ac:classes:X509
Token Service URL: Same token URL from your CPI OAuth client in Step 1
Client Key: Client ID from Step 1
Token Service User: Client ID again from Step 1
Token Service Password: Client Secret from Step 1
Step 7. Configure Principal Propagation in Cloud Connector
Note: The detailed configuration of Principal Propagation using SAP Web Dispatcher as an SSL terminator and reverse proxy is outside the scope of this blog. Since several excellent SAP Community articles already provide step-by-step instructions for that setup, this blog focuses primarily on the OAuth, mTLS, and end-to-end identity propagation aspects of the solution.
For the outbound call, Cloud Connector is responsible for securely forwarding the identity into the on-premises landscape. The mapping between the exposed virtual host and the internal host is combined with Principal Propagation so that the backend call remains identity-aware beyond the network boundary.
As a first step, onboard your CPI subaccount to Cloud Connector. Once it is onboarded, make sure to sync the trust between CPI as the service provider and your ABAP system as the identity provider.
Cloud Connector -> Open your CPI subaccount -> Cloud To On-Premises -> Principal Propagation
The next step is to create a mapping with Type “X509 certificate”.
Open Cloud Connector -> Select your subaccount -> Cloud To On-Premise -> Access Control
Virtual Host: You can choose any logical name for your backend ABAP
Virtual Port: Any port number for your backend ABAP
Internal Host: Your actual ABAP host or FQDN
Internal Port: Your actual ABAP HTTPS port. Remember, for Principal Propagation it has to be HTTPS. If your ABAP system does not have an active HTTPS port, please set that up first.
This mapping is the operational gateway between cloud runtime and the on-premises backend. When Principal Propagation is enabled correctly, Cloud Connector does not just forward traffic; it forwards trusted identity context together with the request path.
The next step is to create a sample certificate that will be used for mapping in the ABAP system. Make sure the sample certificate contains the correct attributes so that the forwarded X.509 Common Name (CN) matches the certificate mapping maintained in ABAP. This is important to ensure that the propagated user identity is recognized correctly and the appropriate authorizations are assigned during processing.
Cloud Connector -> Configuration -> On-Premises -> Principal Propagation
You can verify the actual attributes reaching Cloud Connector in the traces.
Cloud Connector -> Select your CPI subaccount -> Logging and Tracing -> SCC_Core
Make sure to turn on trace level to Debug and CPIC level to 2.
I used the below attributes for mapping in ABAP.
In ABAP:
Tcode: CERTRULE
Also make sure the calling user in ABAP has email mapping in SU01.
Step 8. Activate OAuth 2.0 in the ABAP Consumer Proxy
At the consumer proxy level, the service call is instructed to use OAuth 2.0 rather than Basic Authentication or certificate-only patterns. This aligns the application-layer service consumer with the identity model that was prepared in the previous steps.
SOAMANAGER -> Web Service Configuration
In the below example, I am using the standard proxy: CO_ECPAOX_EE_MD_ORGAS_BNDL_QRY
In the authorization setting, use the OAuth profile created in Step 3.
This setting is important because backend trust alone is not enough. The consuming service object itself must be configured to execute the call using the OAuth profile that matches the propagated identity scenario.
Step 9. Validate End-to-End Connectivity
Validation should prove both connectivity and identity-aware execution. A successful ping confirms technical reachability, while message monitoring confirms that the business-facing integration scenario completed successfully.
The ping result is the initial proof that the destination and connectivity chain are working. It does not replace full functional validation, but it quickly confirms that the path and trust configuration are at least technically usable.
Next, once you activate Principal Propagation in the CPI sender channels, the end-to-end flow is complete. You can verify the successful propagation of user attributes from AS ABAP through CPI and back to ABAP.
The final runtime view should show a completed message or successful processing indicator. This demonstrates that the OAuth client, trust configuration, Principal Propagation, and backend execution have all aligned correctly in one full transaction.
This setup shows how SAP ABAP, CPI, and Cloud Connector can work together to build a secure and identity-aware integration using OAuth 2.0, SAML 2.0 Bearer assertions, and Principal Propagation. Instead of relying on stored technical credentials, the solution allows the original user identity to be trusted, carried forward, and used throughout the complete integration flow. In this example, the setup uses the identity of the calling ABAP user, especially the email address stored in the ABAP user master record, and carries that user context through the entire flow until it reaches the target ABAP system again.
Although the overall process involves several configuration steps across CPI, ABAP, Cloud Connector, trust settings, destinations, and authorization mapping, each step plays an important role in making the end-to-end scenario work correctly. Once all components are aligned properly, the result is a more secure, auditable, and controlled integration pattern for communication between on-premises SAP systems and SAP BTP services.
“}]]
#abap