Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
mandy_krimmel
Advisor
Advisor
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_credentials 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_credentials and the redirect-uris like shown here. Note that the grant type needs to be client_credentials even if you want to configure client certificates.
{
"roles": ["ESBMessaging.send"],
"grant-types":[ "client_credentials"],
"redirect-uris":[],
}

More details on creating service instances in Cloud Foundry can be found in the SAP online documentation at Creating Service Instance and Service Key for Inbound Authentication.

 

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 select the Form based key creation. To upload the external client certificate for the sender system select 'External Certificate' as Key Type, provide a Name and in the External Certificate field add the client certificate in the following PEM-encoded format:
-----BEGIN CERTIFICATE-----MIIHyDCCBrCgAwIB[...]CAq8Tn7kSFDmVnrXe6v8hcQ==-----END CERTIFICATE-----

Note that the client certificate is a PEM-encoded X.509 certificate.

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 Creating Service Instance and Service Key for Inbound Authentication.

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_credentials as grant type.

Note that the grant type needs to be client_credentials even if you want to configure client certificates.
{
"grant-types":[ "client_credentials"],
"redirect-uris":[],
}

More details on creating service instances in Cloud Foundry can be found in the SAP online documentation at Creating Service Instance and Service Key for Inbound Authentication.

 

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 select the Form based key creation. To upload the external client certificate for the sender system select 'External Certificate' as Key Type, provide a Name and in the External Certificate field add the client certificate in the following PEM-encoded format:
-----BEGIN CERTIFICATE-----MIIHyDCCBrCgAwIB[...]CAq8Tn7kSFDmVnrXe6v8hcQ==-----END CERTIFICATE-----

Note that the client certificate is a PEM-encoded X.509 certificate.

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 Creating Service Instance and Service Key for Inbound Authentication.

How to setup OAuth client credential grant for API clients is described in Setup Inbound OAuth Client Credential Grant Authentication for API Clients.
80 Comments
0 Kudos
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 
mandy_krimmel
Advisor
Advisor
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
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
mandy_krimmel
Advisor
Advisor
0 Kudos
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
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"
mandy_krimmel
Advisor
Advisor
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
JaySchwendemann
Active Contributor
0 Kudos
Hi Mandy,

thanks for clarification (and thanks svbconsultiung  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
mandy_krimmel
Advisor
Advisor
Hello Jens,

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

Best regards

Mandy
JaySchwendemann
Active Contributor
0 Kudos
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/7a9b282981784f399615b2fda3c... doesn't say anything about this. I currently assume I need two service keys.

Correct?

Many thanks and kind regards

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

Best regards

Mandy
Ryan-Crosby
Active Contributor
0 Kudos
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
mandy_krimmel
Advisor
Advisor
0 Kudos
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 H...

Best regards

Mandy
Ryan-Crosby
Active Contributor
0 Kudos
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
mandy_krimmel
Advisor
Advisor
0 Kudos
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
Ryan-Crosby
Active Contributor
0 Kudos
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
former_member753196
Discoverer
0 Kudos
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
mandy_krimmel
Advisor
Advisor
0 Kudos
Hello Sarbtej,

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

Best regards

Mandy
former_member753196
Discoverer
0 Kudos
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
mandy_krimmel
Advisor
Advisor
0 Kudos
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
former_member753196
Discoverer
0 Kudos
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
mandy_krimmel
Advisor
Advisor
0 Kudos
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
Ryan-Crosby
Active Contributor
0 Kudos
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-... 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
mandy_krimmel
Advisor
Advisor
0 Kudos
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
Ryan-Crosby
Active Contributor
0 Kudos
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
alishoukat
Explorer
0 Kudos

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 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 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.
mandy_krimmel
Advisor
Advisor
0 Kudos
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
alishoukat
Explorer
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.
0 Kudos
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 ?
mandy_krimmel
Advisor
Advisor
0 Kudos
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 ...

Best regards

Mandy
0 Kudos
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


 

 
mandy_krimmel
Advisor
Advisor
0 Kudos
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
mkmxciii
Explorer
0 Kudos
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
mandy_krimmel
Advisor
Advisor
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
mkmxciii
Explorer
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
0 Kudos
Hi Mandy,

 

Currently we are stuck with Go-Live. As per your suggestion we performed all the activities and deployed the Artifact with AS2 adapter connection. When customer tries to send test data connection is getting failed.

Thanks and Regards,

Raja

rajasegaran.bhuvaneswari@goodbabyint.com

+49 -15145292961

 
mandy_krimmel
Advisor
Advisor
0 Kudos
I request you to open a ticket on LOD-HCI-PI-RT-B2B so that the experts can have a look.

Thank you,

Mandy
JaySchwendemann
Active Contributor
0 Kudos
I too have a connection issue C4C (DEV) --> CI --> x and raised the same question to SAP support. Funnily enough my current problem from C4C DEV persists, while I needed to exchange another client certificate in PRD MKT (PRD) --> CI --> x without a problem

Any clues how you resolved your issue?
0 Kudos
Hi Mandy,

Thanks a lot for this exhaustive guide . I am currently setting this up at our client to call an endpoint created in the Integration Suite.

Just to know, is it supposed to work if I trigger a connection to the endpoint via Postman by mimicking the sender system ? I placed  the Root of the client certificate chain in Postman and triggered a GET towards the CPI endpoint but got an unauthorized error. The call did not arrive at the CPI so I am guessing it got terminated at the load balancer.

As per https://blogs.sap.com/2020/02/24/client-certificate-based-authentication-in-sap-cpi/ , it would work but this blog is anyways for Neo and a different authentication mechanism.

Thanks & Regards,

Satyaki

 

 

 
mandy_krimmel
Advisor
Advisor
0 Kudos
Hello Satyaki,

yes, it should work sending the request via Postman. Authorization error probably means that something in the role assignment is not correct. Are you using x.509 client cert to connect? Maybe you first try with basic auth using client ID and client secret from the service key?

Best regards

Mandy
0 Kudos
Hi Mandy,

thanks for your reply.

The connection from Postman works if I use Oauth2.0 with the basic auth using client ID and client secret from the service key.

I am going to try the Option 2 ( from ur blog) for configuring x.509 certificate for connection ( although it is not recommended but just to test if the certificates work as option 2 is simpler to implement and we are in development phase). In the Service key json file , will it work if I just put the Root certificate ( GlobalSign) of the sender or do I have to paste the entire certificate chain of the sender ?

Also for testing this from Postman, I have to just upload the Root certificate of the sender and select 'No Auth' as Authorization, right ?

Thanks & Regards,

Satyaki
daviddasilva
Active Contributor
0 Kudos
Hi,

When you say root certificate, are you referring to the Key Pair (p12 or pkcs format) certificate? I can test this through postman when I use the Private Key Pair - note you will need to specify the hostname and the password for the Private Key pair in the settings>certificates area in Postman.

Kind regards,

David
mandy_krimmel
Advisor
Advisor
0 Kudos
Hi,

in the service key you need to upload the real client certificate, not only the root certificate.

Also in the postman you need the whole client certificate, not only the root certificate.

Best regards

Mandy
0 Kudos
Hi Mandy/David,

Thanks a lot for your replies.

The certificate authentication now works for me in CF.

Best Regards,

Satyaki

 
priyankgaddala
Explorer
0 Kudos
Thanks Mandy. Your post has been a saviour, I was trying to create Service Key and wondering why it was not including role details.
shahbhat
Product and Topic Expert
Product and Topic Expert
0 Kudos
Hi,

Please refer to this question, it's regarding inbound certificate based authentication in CPI in CloudFoundry:

SAP CPI : Inbound Client Certificate Authentication, Cloud Foundry Environment | SAP Community

Thanks
mandy_krimmel
Advisor
Advisor
0 Kudos
Hello,

in the service key only the client certificate needs to be uploaded, not the whole chain. This client certificate needs to be signed by a approved CA, then the load balancer will accept it. If this does not work, I would suggest to open a ticket so that the experts can have a detailed look.

Best regards

Mandy
ANYOUNG
Explorer
0 Kudos

Hello Mandy,

Your blog is very benefit to a lot of us. Thank you for creating such blog and providing answer to the many questions. Please keep up with the great job.

I have a question with relevant about using the Private Key from SAP Customer Data Cloud for JWT Authentication usage, I'm currently referring to this SAP Help Portal page -> https://help.sap.com/viewer/b6a1e8b75222421a8faf0269e8fbd0dc/2108/en-US/3fac5bcd1f7e4b369080976232ef... and using this OOTB iFlow as my reference https://api.sap.com/integrationflow/Receive_B2C_Customer_Updates_in_SAP_Customer_Data_Cloud

With specific to the Steps 3 -> Using the private key from SAP Customer Data Cloud, generate an X.509 public key and key pair.

I used the Private Key from CDC, to generate an X.509 public key, since there is no guide mentioned, do we generate a self-sign certificate or we need to generate a CSR using the CDC private key and send it to sign by an approved CA? This step is not very clear...

Below are the steps I did, unfortunately, the JWT authentication is still doesn't work.

This is the OpenSSL command I used to create the X.509 public key.
-> openssl req -new -x509 -key Private_Key_cdc.key -out publickey_cdc.cer

After that I use application KeyStore Explorer, to create a JKS KeyStore by using the CDC Private Key and the generated X.509 certificate as Key Pair Type PKCS #8. Then upload it to our CI Keystore for the JWT usage.

I assume the OOTB iFlow JWT authentication should work accordingly. Do you know what steps we could have been missing here?

Look forward to hearing from your advice.

Regards,
Aiivenn

mandy_krimmel
Advisor
Advisor
0 Kudos
Hello

sorry, but I have no experience with SAP Customer Data Cloud. With this question you would have to request help from this experts.

Best regards,

Mandy
ANYOUNG
Explorer
0 Kudos
Thank you, Mandy.

Do you happen to know anyone/blog that I can refer at?

Regards,
Aiivenn
mandy_krimmel
Advisor
Advisor
0 Kudos
I suggest you search in the SAP community for the blogs in the context of SAP Customer Data Cloud.

Best regards

Mandy