Skip to Content
Technical Articles
Author's profile photo Mandy Krimmel

Cloud Integration on CF – How to Setup Secure HTTP Inbound Connection with Client Certificates

This blog describes how to setup secure inbound communication using client certificates when using SAP Cloud Integration in the Cloud Foundry environment. It describes the different configuration options available and gives a step by step description what needs to be configured where. Additional focus of the blog is using custom roles for inbound authorization.

Setup Secure HTTP Inbound Connection with Client Certificates and Custom Roles in Cloud Foundry

A typical task in an integration project is to connect remote systems to the SAP Cloud Integration Tenant. Before going into detailed configuration of the inbound communication let’s first have a short look at the basics.

Basics of Secure System Configuration

The remote system can act either as a sender or a receiver of messages. The setup and the detailed configuration procedure differ according to the communication direction that is being set up: whether a remote system is supposed to send a message to the integration platform or the other way around.

For more detailed information about the different authentication and authorization options refer to the SAP Cloud Integration Documentation, section ‘Connecting a Customer System to Cloud Integration’.

This blog focuses on inbound communication in the Cloud Foundry environment. Inbound communication in Neo environment is described in blog ‘How to Setup Secure HTTP Inbound Connection with Client Certificates’. Outbound communication configuration for Neo and Cloud Foundry is described in blogHow to Setup Secure Outbound HTTP Connection using Keystore Monitor’.

Secure Inbound Communication

For HTTPS based communication towards a Cloud Integration tenant no keystore needs to be maintained in the Integration tenant. Sender system and load balancer need to get the certificates and keys configured as described below. This setup can be used with basic authentication with user and password.

For client certificate-based authentication and authorization in the Cloud Integration tenant in Cloud Foundry the private key pair provisioned with the tenant (alias sap_cloudintegrationcertificate) needs to be available in the keystore and the client certificate used for the inbound call needs to be maintained in the service key. In case the deprecated option to configure the client certificate directly in the integration flow is used, the client certificate is required additionally in the service instance. This is different to the configuration in the Neo environment.

 

Configurations in Sender System

Add Root Certificate from Load Balancer

For secure inbound communication via HTTPS the sender system must trust the load balancer. Therefore the root certificate of the load balancer needs to be part of its trust store.

The easiest way to get the load balancer root certificate is to use the Connectivity Test on the Cloud Integration tenant. The Connectivity Test is available in the Operations View in Web, in section Manage Security. Selecting the Connectivity Tests tile from the Overview page opens the test tool offering tests for different protocols. To connect to a Cloud Integration tenant via the load balancer to get the root certificate select the TLS option. Enter the URL of your runtime node (the URL you want to call from your sender backend) in the Host field. The host name of the runtime node has the format: <tenant>.cfapps.<data center>.hana.ondemand.com. You can find this URL by selecting a tile under Manage Integration Content in the Operations view and selecting the integration flow which should be called.

Execute the connectivity test. If there is in error you may have to uncheck the option ‘Validate Server Certificate‘. The response screen provides the list of certificates from the load balancer because the SSL/TLS connection is terminated by the load balancer. You can use the Download option to download the certificates. A certificates.zip file is created in your local download directory containing all the certificates. From the *zip file select the *.cer file of the root certificate and import this into the trust store of the sender system.

Create Client Certificate

Furthermore, if you want to use Client Certificate authentication, the sender system keystore needs to contain a key pair signed by one of the CAs supported by the load balancer.

Note, that only root certificates are being imported into the Keystore of the SAP Load Balancer. Therefore you as a customer must always assign the whole certificate chain to the certificate to enable the connected component to evaluate the chain of trust.

More information on the supported CAs: Load Balancer Root Certificates Supported by SAP.

Download the client certificate as PEM-encoded X.509 certificate, this is required later when the service key is created.

Configurations on Cloud Integration Tenant in CF

For secure inbound communication using client certificates, on the Cloud Integration tenant the provisioned private key pair with the alias sap_cloudintegrationcertificate is required in the keystore of the Cloud Integration tenant. Furthermore the client certificate needed for the client certificate-based authorization check needs to be configured. In general, there are two configuration options available:

  • Role based authorization
  • Maintaining certificates directly in the integration flow (not recommended)

Note: SAP does not recommend to use basic authentication because of security aspects, details can be found in documentation chapter ‘Basic Authentication’.

1. Option: Role-Based Authorization

The recommended configuration is to use User Role as authorization option in the integration flow sender channel and import the client certificates during service key creation.

Get JSON File for Role in the User Role Monitor

First you need to decide if you want to use the SAP pre-delivered role ESBMessaging.send or use a user-defined role for calling the integration flow.

Use Role ESBMessaging.send

The easiest option for role-based authorization is to use the SAP pre-delivered role ESBMessaging.send. Differently to the Neo environment, where the user roles are configured in the cloud platform cockpit, in the Cloud Foundry environment a monitor exists in the Cloud Integration monitoring to maintain user roles. Open the User Role monitor in section Manage Security in the Monitoring section in the Cloud Integration tenant.

Select the pre-delivered role ESBMessaging.send and choose Download JSON.

The format of the downloaded JSON file looks like this:

{"roles":["ESBMessaging.send"]}

You need this JSON snipped later in the creation of the service instance.

Use User-defined Role

If you want to secure the integration flow by a user-defined role you need to create a new role. In the Cloud Foundry environment a monitor exists in the Cloud Integration monitoring to maintain user roles. Open the User Role monitor in section Manage Security in the Monitoring section in the Cloud Integration tenant.

Create a new role by selecting the Add option.

In the creation dialog enter the role name and a description.

Select the newly created role and choose Download JSON.

The format of the downloaded JSON file looks like this:

{"roles":["Role1"]}

You need this JSON snipped later in the creation of the service instance.

 

Configure Sender Channel

You configure the authorization option in the sender channel in the integration flow. For the adapters supporting client certificate-based authorization you find the Authorization configuration option in the Connection tab. If User Role is selected, an additional entry field for the role to be checked is shown.

The default role provided by SAP is ESBMessaging.send. This role can be used if no additional, integration flow-specific authorization checks are needed. In case only specific certificates/users shall be allowed to send messages to this integration flow you can enter your own role. See above how to create the custom user role in the User Roles monitor in the Cloud Integration monitoring page in section Manage Security.

Authorization

To configure and deploy Integrations flows in WebUI your user needs the role AuthGroup_IntegrationDeveloper.

 

Check for Key Pair ‘sap_cloudintegrationcertificate’ in Keystore Monitor

As already stated, in the Cloud Foundry environment the SAP key pair provisioned on the tenant is required in the tenants keystore in order to use client certificate-based inbound authentication and authorization. Check in the Keystore monitor in section Manage Security that the key pair with alias sap_cloudintegrationcertificate is available and that the key is not expired.

Note that in Trial accounts no SAP key pair is provisioned. Because of this client certificate-based inbound authentication and authorization cannot be used. You can only use basic authentication.

 

Configure Client Certificate-Based Authentication and User Role in the Service Instance in SAP Cloud Platform Cockpit

In order to use client certificate-based inbound authentication, this authentication option has to be activated in the service instance in SAP Cloud Platform Cockpit. When creating the service instance to be used for client certificated-based authentication in the SAP Cloud Platform Cockpit, you need to specify client_x509 as grant type. Furthermore, specify the user role you defined in the integration flow in your sender channel.

The easiest way to configure this is to use the downloaded JSON snipped for the user role and extend it with the grant type client_x509 like shown here:

{
    "roles": ["ESBMessaging.send"],
    "grant-types": ["client_x509"]
}

More details on creating service instances in Cloud Foundry can be found in the SAP online documentation at Creating a Service Instance in the Cloud Foundry Environment.

 

Configure Client Certificate in the Service Key in SAP Cloud Platform Cockpit

The client certificates that will be used to send messages to the integration flow, have to be configured in the service key in the SAP Cloud Platform Cockpit.

After the service instance is available, a service key for the instance needs to be created. In the Create Service Key dialog provide a Name and in the Configuration Parameters add the encoded client certificate in the following JSON format:

{
    "X.509": "-----BEGIN CERTIFICATE-----MIIHyDCCBrCgAwIB[...]CAq8Tn7kSFDmVnrXe6v8hcQ==-----END CERTIFICATE-----"
}

Note that the client certificate is a PEM-encoded X.509 certificate. Remove all line breaks, otherwise the user interface will not accept the entry.

Note that you can create multiple service keys for one service instance with different client certificates. But a client certificate can be assigned to one service instance only once.

More details on defining service keys in the Cloud Foundry environment can be found in the SAP online documentation at Defining a Service Key for the Instance in the Cloud Foundry Environment.

In future a view in the Cloud Integration monitoring section will make this configuration more user-friendly.

2. Option: Configure Certificates directly in Integration Flow

The second option is to configure the certificates for the authorization check directly in the integration flow. But this option is not recommended because changes to the certificate will always cause short downtimes as the integration flow needs to be restarted. Furthermore, in the Cloud Foundry environment the client certificate has to be added to the service key additionally.

Configure Sender Channel

In the sender channel in the integration flow authorization can be configured for the adapters supporting client certificate-based authorization. The Authorization configuration option is available in the Connection tab of the channel. If Client Certificate is selected a table is shown, where you can add the client certificates. Select Add to add a new row to the table. In the row you can open the upload dialog for a certificate. Via Upload from File System you can browse the certificate file and add it to the channel.

You can add several certificates to the integration flow sender channel. But be aware that each update in the integration flow needs a redeployment of the integration flow and so is always causing a short downtime. This means, also during certificate renewal of the client certificate you must redeploy the integration flow, causing a short downtime. Exactly because of this disadvantage SAP recommends to use the User Role Authorization option with user to certificate mapping.

Authorization

To configure Integrations flows your user needs the role AuthGroup_IntegrationDeveloper.

Check for Key Pair ‘sap_cloudintegrationcertificate’ in Keystore Monitor

As already stated, in the Cloud Foundry environment the SAP key pair provisioned in the tenant is required in the keystore in order to use client certificate-based inbound authentication. Check in the Keystore monitor that it is available and that the key is not expired.

Note that in Trial accounts no SAP key pair is provisioned. Because of this client certificate-based inbound authentication cannot be used. You can only use basic authentication with clientid and clientsecret generated in the service key.

.

Configure Client Certificate Based Authentication in the Service Instance in SAP Cloud Platform Cockpit

If you like to use client certificate-based inbound authentication, you have to activate this option in the service instance in SAP Cloud Platform Cockpit. When creating the service instance to be used for client certificated-based authentication in the SAP Cloud Platform Cockpit, you need to specify client_x509 as grant type:

{
    "grant-types": ["client_x509"]
}

More details on creating service instances in Cloud Foundry can be found in the SAP online documentation at Creating a Service Instance in the Cloud Foundry Environment.

 

Configure Client Certificate in the Service Key in SAP Cloud Platform Cockpit

Configure the client certificate that will be used to send messages to the integration flow in the service key in the SAP Cloud Platform Cockpit.

After the service instance is available, a service key for the instance needs to be created. In the Create Service Key dialog provide a Name and in the Configuration Parameters add the encoded client certificate in the following JSON format:

{
    "X.509": "-----BEGIN CERTIFICATE-----MIIHyDCCBrCgAwIB[...]CAq8Tn7kSFDmVnrXe6v8hcQ==-----END CERTIFICATE-----"
}

Note that the client certificate is a PEM-encoded X.509 certificate. Remove all line breaks, otherwise the user interface will not accept the entry.

Note that you can create multiple service keys for one service instance with different client certificates. But a client certificate can be assigned to one service instance only once.

More details on defining service keys in the Cloud Foundry environment can be found in the SAP online documentation at Defining a Service Key for the Instance in the Cloud Foundry Environment.

In future a view in the Cloud Integration monitoring section will make this configuration more user-friendly.

Assigned tags

      34 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Satish Bhagwat
      Satish Bhagwat

      Hi Mandy, a very nice, detailed blog that I am finding useful even at the end of 2020!  I was wondering if you could clarify a few details, considering CF will now be the only CP-CPI option available from 2021...

      1. What is the significance of the keypair sap_cloudintegrationcertificate? In a 2-way SSL handshake between a client and CPI acting as a server, does the client need to have the CA cert of this keypair in their trusted cert store, rather than the CA cert of the deployed integration flow?  These 2 CA certs are different as per my experience.
      2. The Certificate-to-User authentication option does not appear in CF anymore.  For the sender HTTPS type adapters, only two options appear to be present - basic auth (userid/pw) or client certificate.  Does this mean that when building the sender HTTPS channel, if the "Client Certificate" authentication option is chosen, then we must provide the client certificate at the integration flow level as well?  Can you please provide comments on this?
      3. When generating the service instance of type "Process Integration Runtime" in SAP Cloud Platform for client certificate authentication, would it suffice to generate the service instance by only specifying {"grant-types": ["client_x509"] } or must we also specify the role (either default and/or custom, such as {
        "roles": ["ESBMessaging.send"],
        "grant-types": ["client_x509"]
        }, and then provision a service key with the client certificate's Base64 content?

      Thank you very much, and wish you a Happy New 2021!

      Regards

      Satish Bhagwat 

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      1. the sap_cloudintegrationcertificate keypair is not needed in CF for SSL handshake if CPI acts as the server. The client only needs the CA of the load balancer in its keystore (as mentioned in the blog). The sap_cloudintegrationcertificate keypair is mandatory for client certificate-based authentication because there the key pair is also used for internal communication between the microservices in CF. This means you can use client certificate based inbound authentication only if this keypair is available in the keystore.
      2. As mentioned in the blog the user-certificate mapping is different in CF. There you don't map the client certificate to a user, but you assign it to a service key. In the sender channel you can still select user role and client certificate as in Neo, only the configuration for user-role is different. With user role you can use basic authentication or client certificate based authentication (option 1 described in the blog), there you don't need to maintain the certificate in the integration flow.
      3. As written in the blog if you want to use user role based authentication (with or without Client certificates) you also have to specifiy the user role in the service instance. Only with Option 2 (Client Certificate directly maintained in the integration flow) you dont need the user role.

      I hope this clarifies?

      BR

      Mandy

      Author's profile photo Jens Schwendemann
      Jens Schwendemann

      Hi Mandy,

      thanks for clarification (and thanks Satish Bhagwat  for rightfully pointing this out). I must admit it doesn't particularly shed a trustworthy light onto your service. I mean It's allright that you use the same security artifacts for internal communication with the CF framework / runtime but since you are in complete ownership of the stack and the provisioning procedure including you (as SAP) prohibiting the deletion of SAP owned security artifacts like "sap_cloudintegrationcertificate" (for a good reason, of course) this then would mainly mean you don't trust your own provisioning procedure to always have that "sap_cloudintegrationcertificate" readily available?

      Or are there other situations where this could get lost or deleted?

      Forgive me, for maybe being particularly salty but doing a current migration from Neo to CF I feel you are really more selling (forcing upon the client) a PaaS instead of a SaaS when it comes to Cloud Integration.

       

      Cheers

      Jens

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello Jens,

      thank you for your feedback. We are already planning to improve this, but this needs some time.

      Best regards

      Mandy

      Author's profile photo Satish Bhagwat
      Satish Bhagwat

      Hi Mandy, I appreciate your response. The issue I have been facing is as follows: Please see the question posted on the forum (URL link = https://answers.sap.com/questions/13219259/error-while-attempting-salesforce-to-cpi-integrati.html).

      In a subscribed (NOT Trial) CF CPI setup, attempting to have a client certificate-based authentication and authorization from a Salesforce client to CPI.
      This interface works properly with a basic auth; however, ran into problem when attempting to make it work using client certificate authentication.

      Salesforce log shows the following error:

      USER_DEBUG [67]|DEBUG|RESPONSE_STRING<InvalidClientException><error>invalid_client</error><error_description>Either client certificate is not configured in any service key of a Process Integration Runtime service instance or client-certificate authentication was not enabled for your tenant (key-pair with alias 'sap_cloudintegrationcertificate' does not exist in the keystore or was not mapped to the UAA instance): sb-it-rt-xxxxxxxxxxxxxxxx!b46, client certificate MIIDjzCCAnegAwIBAgINVPYo.

      This error is the reason I was asking about the clarification on the key-pair with alias 'sap_cloudintegrationcertificate'.

      I was able to confirm that the CA cert of the deployed integration flow as well as the CA cert of the key-pair with alias 'sap_cloudintegrationcertificate' do exist in the CA certificate entries under the Trusted Keystore of Salesforce.

      It appears that the interface call from Salesforce gets stopped at the Load Balancer and never reaches the CPI tenant, since no incoming call details show up in CPI Monitor.

      For now, I used the keypair of a S-user Passport in Salesforce. Am I correct that this should suffice as a CA-certified keypair, since the CA of SAP Passport is trusted by the Load balancer?

      I then set up the service instance of the type "Process Integration Runtime" and the service key with the client cert details corresponding to the public key of the S-user passport keypair.  I have successfully implemented outbound IDocs from on-prem ECC to CPI using cert-based auth approach, which also requires the service key detail to be done right in SAP Cloud Platform; so I think the service key part was done correctly.

      Can you share your perspective if you notice anything that needs to be corrected?  I would very much appreciate that!

      Best regards

      Satish Bhagwat

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello Satish,

      if the sap_cloudintegrationcertificate key pair is available in the keystore of your tenant and you have maintained the client certificate in the service key in a CPI runtime service instance configuring X.509 authentication ("grant-types": ["client_x509"]) this should work.

      The error indicates that there is something wrongly configured in the service instance and/or service key.

      I would suggest you re-check this configuration. If you do not find the problem I would suggest you open a ticket on LOD-HCI-PI-RT.

      Best regards

      Mandy

      Author's profile photo Satish Bhagwat
      Satish Bhagwat

      Hi Mandy, I am responding to let you know that I was able to fix the issue, and was also able to recreate the error.  Your informative blog as well as your subsequent helpful comments to my questions were instrumental in finding the resolution and recreation of the error.  I very much appreciate that!

      I was receiving the error that I reported earlier, because I had used the same S-user Passport keypair in different client applications (Salesforce, SAP CRM, etc.) for testing purpose.  Not realizing that the public key contents were identical, I had created multiple service keys in different service instances for the same public certificate Base 64 content.  When I removed multiple service keys having identical Base64 content and left only one service key in place, the interface started working properly.

      This is the observed SAP Cloud Platform behavior -

      When a service key was attempted to be created within a service instance with the same service key parameters (i.e., Base64 certificate data placed in JSON as the value of the variable "X.509"), the SAP CP logic properly stopped that attempt with an error to generate a service key.

      However, multiple service keys could be generated from the same Base64 content if the keys were created in different service instances.  For example, I was able to create service keys with identical Base64 content in instances “ClientCertificateAuth”, “rolenx509” and “x509only” (Service key names were same in one case and different in another; but Base64 content was identical every time.).

      When there are multiple service keys with the same Base64 content, AND AFTER a lag time of exactly 1 hour, then I was able to see the error that I reported earlier.  If a connection test was attempted within this 1 hour, I still received a HTTP 200 OK response.  So there appears to be a lifespan of 60 minutes, similar to the OAuth2 bearer token lifetime of 4,199 seconds (appx 70 minutes).

      The error was exactly the same error that I had reported earlier.

      error = "invalid_client", error_description="Either client certificate is not configured in any service key of a Process Integration Runtime service instance or client-certificate authentication was not enabled for your tenant (key-pair with alias 'sap_cloudintegrationcertificate' does not exist in the keystore or was not mapped to the UAA instance): sb-it-rt-xxxxxxxnonprodcpi!b46, client certificate MIIDjzCC<Rest of the Base64 stuff>cF5sKGPn, message: 400 Bad Request"

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      thank you for the detailed analysis. We will check if we can improve the UIs to not allow same certificate in different service instances.

      Best regards

      Mandy

      Author's profile photo Jens Schwendemann
      Jens Schwendemann

      Is it supported to have multiple certificates within one key, e.g. for certificate rollover so something like this

      certificate": [
        "-----BEGIN CERTIFICATE----- ...-----END CERTIFICATE-----",
        "-----BEGIN CERTIFICATE----- ...-----END CERTIFICATE-----"
      ]

      https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/7a9b282981784f399615b2fda3cda062.html doesn't say anything about this. I currently assume I need two service keys.

      Correct?

      Many thanks and kind regards

      Jens

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Yes, you need to separate service keys. It is not possible to have bother certificates in one service key.

      Best regards

      Mandy

      Author's profile photo Ryan Crosby
      Ryan Crosby

      Hi Mandy,

      So with respect to load balancing this means we would have to generate a key pair, and have it signed by one of the approved certificate authorities to do testing in a non-productive tenant?  E.g. AS2 testing where we would want to unit test different flows (camel framework) related to error handling, logging, etc.?  I have a local Mendelson client for sending test messages, but it is delivered with certificates purely for testing and one has the option to create other self-signed certificates.  Trying to get more clarification because I am a many year veteran of SAP PI/PO but have never used CPI until the last few days.

      Also, if we do not have a process integration runtime service created in the BTP is that a problem?  I have seen some references to it in other blogs and help articles, but I do not see it in our setup.

       

      Regards,

      Ryan

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello Ryan,

      there are different authentication options available, not only the client certificate based authentication described in the blog, for all options please refer to the official Cloud Integration documentation:

      Setting Up Inbound HTTP Connections (Integration Flow Processing), Cloud Foundry Environment - SAP Help Portal

      Best regards

      Mandy

      Author's profile photo Ryan Crosby
      Ryan Crosby

      Hi Mandy,

       

      Thank you for the response.  I did find some content on how to setup the basic authentication for testing.  I cannot get Mendelson to connect properly for an AS2 test, but I was able to simulate a test with the HTTP adapter.  It gives some complaint about protocol, I think related to certificates, but no log is generated so I cannot figure out what is missing on that one.

       

       

      Regards,

      Ryan

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      concerning AS2 and usage of mendelson you may refer to this blog: B2B Capabilities in SAP Cloud Integration – Part 1 | SAP Blogs

      If this does not help I would suggest you open a ticket, this is hard to analyze via the blog comments.

      Best regards

      Mandy

      Author's profile photo Ryan Crosby
      Ryan Crosby

      Hi Mandy,

      Yes, I had been referring to that blog to see what was different between this and PO/PI, but it is not working.  I'm opening an incident right now because it seems to be tied to the keys for the SSL connection.

       

      Regards,

      Ryan

      Author's profile photo Ryan Crosby
      Ryan Crosby

      Hi Mandy,

      Maybe you could point me in the right direction on this one?  I'm looking at some older blogs, but not sure if they are specific to only the Neo environment.  I'm trying to figure out how we identify a partner id in the Partner Directory by certificate - I have tried the following blog: https://blogs.sap.com/2017/08/24/cloud-integration-partner-directory-sender-partner-connecting-with-client-certificate-authentication/ and I get this error:

      It is not clear how the partner mapping is maintained so we can access the necessary string value pairs.  When I use the OData API to view partners I get nothing despite having sent messages previously.  I also tried explicitly creating a partner to see what the API would do and it mentions they are created implicitly.  Implicit creation does not make the link clear especially when I do not see any entries and I cannot find any help or blogs on the topic that are recent.

       

      Regards,

      Ryan

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      In CF there is no such entity as Certificate-User Mapping. In general the PD as such works same in Neo and CF, you can store key/value pairs for specific partners.

      I would point you to the following design guidelines for the partner directory usage:

      Use the Partner Directory Appropriately - SAP Help Portal

      Hope this helps you to figure the problem out.

      best regards

      Mandy

      Author's profile photo Ryan Crosby
      Ryan Crosby

      Hi Mandy,

      Thank you, as that at least got me started.  It may be helpful for the official help documentation to point out that the AuthorizedUsers should match the clientId from the service keys that are generated.  Without explicitly mentioning this it wastes a lot of time unit testing, tracing, logging, etc. to determine that the connection between the arbitrary partner that we create is linked to the information in the service key in another system.

       

      Regards,

      Ryan

      Author's profile photo Sarbtej Singh
      Sarbtej Singh

      Hi Mandy,

      There is a requirement to enable both basic authentication to authorize the HTTP Client to call the Integration Flow Endpoint using grant type as client_credentials and certificate based authentication using grant type as client_x509 but both grant types cannot be combined for the service instance. So, how can this requirement be implemented.

       

      Best Regards,

      Sarbtej

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello Sarbtej,

      this is currently not planned, but we will evaluate and if possible to add it ad new requirement.

      Best regards

      Mandy

      Author's profile photo Sarbtej Singh
      Sarbtej Singh

      Hi Mandy,

      we can create two Process Integration Runtime instance, one with grant type as client credentials and other with grant type as client_x509 and this will allow both basic and client certificate authentication for an Integration Flow?

       

      Best Regards,

      Sarbtej

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      ok, looks like I misunderstood your first question, you do not want both to be checked and only then allow execution (dual authentication)? This is what is not possible.

      But to allow both options in parallel, meaning user can come with either basic auth or credential is already possible. Simply use the role based option in the integration fflow. then this flow can be accessed by both options, with a certificate assigned in user-certificate mapping, and also with a user/password if he has the correc role assigned.

      BR

      Mandy

      Author's profile photo Sarbtej Singh
      Sarbtej Singh

      Hi Mandy,

      My requirement is in CF CPI to enable basic and client certificate authentication for an Integration Flow but in CF there is no option of user to certificate mapping.

       

      Best Regards,

      Sarbtej

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      In CF you can enable this via a service instance for OAuth/Basic and a second service instance for client certificate based authentication.

      Then both is possible in parallel.

      BR

      Mandy

      Author's profile photo Shoukat Ali
      Shoukat Ali

      I am using CPI Trial account.

      configured sender SOAP adapter with User Role and ESBMessaging.

      When i invoke this in soapUI. it works with Basic authentication.

      soap%20ui

      soap ui

      then, i tried to invoke it from an S4 on premise system.

      i created Service consumer with CPI wsdl in se80 and created a logical port. i was able to read wsdl and logical port generated successfully.

      when i am testing the service consumer in se80. it's not working with the credentials.

      error%20in%20se80

       

      error in se80

      what am i missing here? please help.

      i have imported certificates of CPI in strust. also imported  certificates of S4 in CPI keystore.

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      this is really hard to evaluate using your comments in the blog.

      Some thoughts:

      • check if the call reaches Cloud Integration
      • check the message monitoring in Cloud Integration. It looks like the connection itself works but there is an issue when the integration flow is executed

      Best regards

      Mandy

      Author's profile photo Shoukat Ali
      Shoukat Ali

      Thanks for your response.

      Issue got resolved.

      As I am using CPI trial account, i had to export the 'WSDL without policies' from the endpoint details page.

      And in the soamanager in S4 system, I had to use the wsdl file instead of URL access.

      Author's profile photo Y Z
      Y Z

      Hi Mandy,

       

      For cloud integration content deployed on PO (CPI RUNTIME) , does all the above steps hold true ?

      Also all the certificates like loadbalancer certificate generated from CPI valid on PO ?

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello;

      no, in case of PO runtime the security setup needs to be done in the Netweaver as per the Netweaver documentation.

      For additional details please check 2195773 - Cloud Integration Content in SAP Process Orchestration 7.50 - Known Constraints - SAP ONE Support Launchpad

      Best regards

      Mandy

      Author's profile photo Y Z
      Y Z

      Hi Mandy,

      Thanks for the reply , really appreciate it .

      I had seen that note but i thought that it says that if you are using client certificate option on sender adapters as opposed to user role option (which SAP recommends now) then its an issue and we need to use SAP web dispatcher as component for terminating SSL.

       

      I thought if we configured the sender adapters with user role , then we have both the options below available, considering we have options to download and upload all the security artifacts.

      1. Client certificate authentication
      2. OAuth with client credentials grant

       

       

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello

      the note says:

      <<Client Certificate Authorization on sender channels requires the usage of a SAP Web Dispatcher as component for terminating SSL and forwarding HTTP header ssl_client_cert.
      It is recommended to use User Role Authorization instead. Client certificates can be mapped to allowed users via NetWeaver Administrator Identity Management.>>

      This means if you use user role you can use Client Certificates as well mapping them to users in the NetWeaver Identity Management.

      Best regards

      Mandy

      Author's profile photo Mae Katherine Mercado
      Mae Katherine Mercado

      Hi, Mandy.

      Thank you for this detailed article. I'm trying to implement option 1 in our tenant but I am encountering an issue when creating the service key.

      I can create the service instance correctly with the grant-types and roles populated:

      But when creating the service key within the instance, the grant-types and roles are not assigned:

      {
        "oauth": {
          "clientid": "<clientid>",
          "url": "<URL>",
          "certificate": "<Certificate>"
        }
      }

      Am I missing anything here? Thank you!

      Regards,

      Mae

      Author's profile photo Mandy Krimmel
      Mandy Krimmel
      Blog Post Author

      Hello,

      there was a change done. The configuration details were removed from the service keys. Instead you can check the configuration of the service instance by selecting the instance and choose “Show parameters” from the menu on the right top in the cockpit UI.

      Best regards

      Mandy

      Author's profile photo Mae Katherine Mercado
      Mae Katherine Mercado

      Hi, Mandy.

       

      Thank you for sharing! This helps a lot as we were wondering if this was the cause of our connection issue.

       

      Regards,

      Mae