Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Arundathi
Participant
1,492

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:

  1. BTP Configuration
  2. Cloud Connector and S4HANA Configuration

    Picture1.jpg

     

     


     

     
    Process flow steps:          

    1. OAuth Token generated in IDP service using client id and secret.
    2. Invoking API resources published in Azure API Management platform using the OAuth token
    3. Azure APIM to BTP CI: Client certificate-based authentication
    4. Azure APIM will send the API request along with the Application ID as a header parameter to BTP CI
    5. BTP CI integration flow step will do a VM table lookup to get the corresponding Client ID defined in respective Connectivity service.
    6. 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.
    7. BTP CI iFlow step will attach the fetched JWT token to the header “SAP-Connectivity-Technical-Authentication” and send the API request to SCC.
    8. BTP CI -> SCC: It is through secure tunnel (one time trust activity)
    9. SCC -> SAP S/4HANA is based on mTLS authentication (WD forwards the short-lived certificate for the system user from SCC to S/4)
    10. SCC will evaluate the JWT token and generate a short-lived certificate specific to the client ID
    11. In SAP S/4, API request with short-lived certificate is evaluated against the CERTRULE entries and corresponding SAP system user is validated.
    12. 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 belowS1_BTP Dest.jpg

    S1_BTP Dest2.jpg

    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.
      S1_BTP CS.jpg

       Now create service keys for both the connectivity service subscriptions.

    S1_BTP CS1.jpg

     

    S1_BTP CS2.jpg

    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.

    CI_1.jpg

    CI_2.jpg

     The User shown below is the Connectivity service instance – Client-ID

    CI_3.jpg

     CI_4.jpg

     Step 1:  HTTPs call with Application ID passed in header.

    CI_S1.jpg

     Step 2: Groovy script to fetch the connectivity service (TechnicalUser1) username maintained in SAP CI security material. 

    CI_S2.jpg

     Step 3: Routing condition to validate if the Application ID. 

    CI_S3.jpg

     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.

    CI_S4.jpg

    Step 5: Get the access token from connectivity service call response and set the header parameter “SAP-Connectivity-Technical-Authentication”.

    CI_S5.jpg

     Step 6: Call the S4HANA OData API

    CI_S6.jpg

     Step 7: If the Application ID or the source system is invalid pass the error response to source system

    CI_S7.jpg

    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 
    S2_1.jpg

    S2_2.jpg

    S2_3.jpg

     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.
    S2_4.jpg

     

    S2_5.jpg

     

     

    Download the system cert public key from cloud connector

    CA certificate:

    Create self-signed CA certificate.

    S2_6.jpg

     

     


    S2_7.jpg

     

    Use Subject patterns of principle propagation as CN=${name} as we are using client ids
    S2_8.jpg

    Step 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.

    S2_9.jpg

     

    S2_10.jpg

    Step 5:
    Set the profile parameter icm/HTTPS/verify_client = 1
    S2_11.jpg

    Step 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”.
    S2_12.jpg

    S2_13.jpg

     Click on generate.

    Use the downloaded certificate in S4 certrule to map for each client id.
    S2_14.jpg

     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.

    1. Basic Authentication
    2. Logon using SSL Certificate
      S2_15.jpg

      Step 9:
      Consider steps mentioned in link below needed to setup Certificate forwarding through Webdispatcher.

      https://help.sap.com/docs/ABAP_PLATFORM_NEW/683d6a1797a34730a6e005d1e8de6f22/2a6cec67c50842aab1444f7...

      Testing:

      Positive Test case: Valid User
      Trigger SAP CI API from postman with Application ID in header:

      T1.jpg

      Get the Connectivity service Client ID from Value mapping.

      Fetch JWT Token from Connectivity service and pass it in “SAP-Connectivity-Technical-Authentication” header.

      T2.jpg

      Short lived certificate created in Cloud connector.
      User validated in S4HANA and response from S4HANA.

      T3.jpg

       HTTP response 200 in postmanT4.jpg

      Negative Test case: InValid User
      Trigger SAP CI API from postman with Application ID in header:

      T5.jpg

      The Connectivity service Client ID not received from Value mapping.
      Call fails due to invalid Application ID/user.

      T6.jpg

      HTTP response 401 in postman

      T7.jpg

       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-propagation

      https://discovery-center.cloud.sap/serviceCatalog/connectivity-service?region=all

      https://help.sap.com/docs/ABAP_PLATFORM_NEW/683d6a1797a34730a6e005d1e8de6f22/2a6cec67c50842aab1444f7...

2 Comments
Labels in this area