Requirement:
Establish trusted relationship/connectivity between source systems at client side to Azure APIM and from Azure APIM to S4HANA system via CI and cloud connector using short lived certificate i.e., principal propagation.
Overview
Principal propagation means the ability to forward the user context of a message unchanged from the sender to the receiver. It enables authentication of a message in the receiver system with the same user that issued the message in the corresponding sender system. Thus, the receiver application is virtually part of the sender application, and the permissions and audit functions of the receiver application can be applied to the original user of the sender application.
Source system is authenticated at Azure APIM via OAuth token generated by the IDP. APIM will pass the source identity as header in the API call. Source identity is mapped to a connectivity service user in S4HANA. SAP CI, SAP connectivity service and SCC validate/authenticate the source identity and generate a short-lived certificate to access S4HANA API. Hence only the authorised system is allowed to access the S4HANA API.
This blog illustrates how to apply the principal propagation to validate source technical system in S4HANA using SAP BTP CI and SAP BTP Connectivity service.
My sincere gratitude to Amir Mahakud and Pradeep Nagaraja Vasa for their support in developing the solution and preparing this blog.
Solution:
The approach will be divided into 2 sections:
- BTP Configuration
- Cloud Connector and S4HANA Configuration
Process flow steps:- OAuth Token generated in IDP service using client id and secret.
- Invoking API resources published in Azure API Management platform using the OAuth token
- Azure APIM to BTP CI: Client certificate-based authentication
- Azure APIM will send the API request along with the Application ID as a header parameter to BTP CI
- BTP CI integration flow step will do a VM table lookup to get the corresponding Client ID defined in respective Connectivity service.
- BTP CI iFlow step will use the client ID and secret specific to the connectivity service to fetch the JWT token from the connectivity service.
- BTP CI iFlow step will attach the fetched JWT token to the header “SAP-Connectivity-Technical-Authentication” and send the API request to SCC.
- BTP CI -> SCC: It is through secure tunnel (one time trust activity)
- SCC -> SAP S/4HANA is based on mTLS authentication (WD forwards the short-lived certificate for the system user from SCC to S/4)
- SCC will evaluate the JWT token and generate a short-lived certificate specific to the client ID
- In SAP S/4, API request with short-lived certificate is evaluated against the CERTRULE entries and corresponding SAP system user is validated.
- SAP System user roles and authorization is checked, and OData/SOAP API is executed under the specific system user.
Section1: BTP Configuration
This section includes BTP Destination configuration, SAP CI configuration and Connectivity Service subscription and configuration.
BTP Destination Configuration:
Create a destination for PP (Principle Propagation) as below
CONNECTIVITY SERVICE:
In the same subaccount of CI, subscribe “connectivity service” with plan “lite”.
We need one service subscription for each source system as
- Each source system will be using different application id.
- Each application ID should correspond to one client ID of connectivity service.
- Client ID in the same connectivity service will be same even though we create multiple service keys.
Now create service keys for both the connectivity service subscriptions.
SAP CI:
A VM table is maintained to get the corresponding Client ID defined in respective Connectivity service for the Application ID passed from source system. Below iflow depicts the configurations in CI iflow and value mapping table.
The User shown below is the Connectivity service instance – Client-ID
Step 1: HTTPs call with Application ID passed in header.
Step 2: Groovy script to fetch the connectivity service (TechnicalUser1) username maintained in SAP CI security material.
Step 3: Routing condition to validate if the Application ID.
Step 4: If the application ID is valid call Connectivity service to get the JWT token.
To get the connectivity service credentials create an instance and service key in BTP.
Step 5: Get the access token from connectivity service call response and set the header parameter “SAP-Connectivity-Technical-Authentication”.
Step 6: Call the S4HANA OData API
Step 7: If the Application ID or the source system is invalid pass the error response to source system
Section-2: S4HANA side configuration:
Step 1: Login to cloud connector->Select the subaccount for CI->Click on “Cloud to On-premise” connections
->Create a HTTPS connection to S4 system
“Principal Type” set to “X.509 certificate.”
Create “Access Control” entry for S4 Hana
Step 2: Create its system certificate in SCC and Download the certificate.
Goto Configurations->On-premise
Get the signed key pair(p12) from certificate authority, then import the certificate.
Download the system cert public key from cloud connector
CA certificate:
Create self-signed CA certificate.
Use Subject patterns of principle propagation as CN=${name} as we are using client idsStep 3: Import Certificate to S4
Import the SCC system certificate in S/4 HANA STRUST under SSL server standard at S4.
Step 4: Set Parameters in S/4
Set Profile parameter icm/trusted_reverse_proxy to the SCC system certificate.Step 5:
Set the profile parameter icm/HTTPS/verify_client = 1Step 6: Certificate to user mapping in S4
Map the SCC certificate to a system user with sufficient authorization via Transaction code CERTRULE.
For Client certificate (Certificate based authentication), use sample certificate generated at SCC with client ID to s4 user
In SCC, click on “create a sample certificate”.Click on generate.
Use the downloaded certificate in S4 certrule to map for each client id.
Use all mapping in “Explicit Mapping” in certrule.
For mutual authentication we are mapping system certificate from cloud connector to S4 user (TU_SSO_PP). Connectivity service certificates are mapped to TU_SSO_PP1 and TU_SSO_PP2.
Step 7:
Set the profile parameter value to 1
login/certificate_mapping_rulebased=1
Step 8: Adjust the login procedure list of ICF service S4
Adjust the login procedure list for the ICF services which are to be invoked as a part of Integration. (SAP Note _ 2573379)The login procedure list should follow below sequence.
- Basic Authentication
- Logon using SSL Certificate
Step 9:
Consider steps mentioned in link below needed to setup Certificate forwarding through Webdispatcher.Testing:
Positive Test case: Valid User
Trigger SAP CI API from postman with Application ID in header:Get the Connectivity service Client ID from Value mapping.
Fetch JWT Token from Connectivity service and pass it in “SAP-Connectivity-Technical-Authentication” header.
Short lived certificate created in Cloud connector.
User validated in S4HANA and response from S4HANA.HTTP response 200 in postman
Negative Test case: InValid User
Trigger SAP CI API from postman with Application ID in header:The Connectivity service Client ID not received from Value mapping.
Call fails due to invalid Application ID/user.HTTP response 401 in postman
Conclusion:
In this blog we saw how to establish trusted connectivity between source systems at client side to S4HANA system via Azure APIM, SAP CI and cloud connector using short lived certificate i.e., principal propagation.
Reference:
https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/configuring-principal-propagationhttps://discovery-center.cloud.sap/serviceCatalog/connectivity-service?region=all
- SAP Managed Tags:
2 Comments
