Principal Propagation on Mobile Services in Cloud Foundry Environment

[horsa11225]

We are developing an Android SDK application from Mobile Services in a Cloud Foundry environment and we need to implement a Principal Propagation mechanism.

We followed different guides on Help SAP portal but we cannot able to achieve our goal.

Based basically on following guides:

https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/c84d4d0b12d34890b334998185f...

https://blogs.sap.com/2017/06/22/how-to-guide-principal-propagation-in-an-https-scenario/

We have configured the various actors in principal propagation mechanism as follow:

CLOUD CONNECTOR:

We have generated the below certificates to pass SAP side.

In Principal Propagation tab we noted the first difference between our configuration and guide’s tutorial:

Our cloud foundry:

NEO solution like guide’s references:

SAP SIDE:

Certificates generated above is passed in SAP system, inserted in STRUST as in the official guide. Instance parameters have been added:

“login/certificate_mapping_rulebased” parameter is setted to 1, so we mapped user using CERTRULE transaction:

SCP Cockpit

Cloud Connector is present and available in our cloud foundry subaccount:

Mobile Service:

We have configured our destination as follow:

But when we tries to ping, we received an unauthorized error and we cannot consume the OData service.

Important: We are able to consume OData service in Basic Authentication.

Why we received the error above? How we can resolve? There are some guides to follow?

Thanks.

[AntalP · Accepted solution]

Hi Alberto,

Could you check the scenario in the backend system, set the ICM trace level to 3 and look for the TLS handshake, if the cloud connector sends the client certificate (system certificate) and if the HTTP header contains the ssl_client_cert certificate which is issued by the CA certificate in the cloud connector.

Best regards,

Antal

[horsa11225 · Accepted solution]

Hi Antal,

thank you so much. With trace level you suggested we managed to find the problem.

The problem was in the certificates passed to SAP and generated on cloud connector.

We discovered that when we generate certificate of each user (see image), we must use the mail associated to S-USER instead of the S-USER itself.