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: 
Domi
Active Contributor
8,479
If you want to setup Principal Propagation you will definitely need the following links and How-To guides. You will find nearly everything to configure your SCP and ABAP backend to use Principal Propagation!

https://launchpad.support.sap.com/#/notes/2462533
https://launchpad.support.sap.com/#/notes/2052899
https://help.sap.com/viewer/cca91383641e40ffbe03bdc78f00f681/Cloud/en-US/a8bb87a72d094e0d981d2b1f67d...
https://blogs.sap.com/2017/06/22/how-to-guide-principal-propagation-in-an-https-scenario/
https://blogs.sap.com/?s=principal+propagation

 

But when setting up Principal Propagation in different environments, I faced some other issues. Here are some more hints from my journey:

icm/trusted_reverse_proxy_<x>


Always use parameter icm/trusted_reverse_proxy_<x>, if available! icm/HTTPS/trust_client_with_subject and icm/HTTPS/trust_client_with_issuer didn't work for me!

Browser Cache


Always completely close your browser to check a changed configuration! Also use incognito mode and sometimes even clear the whole browser cache - especially if you have several accounts, sub accounts and user.

SSSLERR_SSL_ACCEPT - received a fatal TLS certificate unknown alert message from the peer


In the ICM Trace file you see something like this:
<<- ERROR: SapSSLSessionStart(sssl_hdl=000000000790FBA0)==SSSLERR_SSL_ACCEPT
*** ERROR => IcmConnInitServerSSL: SapSSLSessionStart returned (-56): SSSLERR_SSL_ACCEPT [icxxconn.c 1737]
SSL_get_state()==0x1180 "TLS read client certificate A"
*** ERROR during SecuSSL_SessionStart() from SSL_accept()==SSL_ERROR_SSL
session uses PSE file ".....SAPSSLS.pse"
SecuSSL_SessionStart: SSL_accept() failed (536875078/0x20001046)
=> "received a fatal TLS certificate unknown alert message from the peer"

 

And in the cloud connector log ljs_trace.log you find this:
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1226) 
at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:1192)
at sun.security.ssl.AbstractTrustManagerWrapper.checkServerTrusted(SSLContextImpl.java:1106)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1626) ... 28 more Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed on signature algorithm: MD5withRSA
at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:295)
at sun.security.ssl.AbstractTrustManagerWrapper.checkAlgorithmConstraints(SSLContextImpl.java:1222) ... 31 more|
+0100#INFO#com.sap.scc.rt#Thread-13# #SccEndpointValidator has thrown exception for HTTPS://xxx.yyy.zzz:8443: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Certificates do not conform to algorithm constraints
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)

 

Please check Note 1848999 - Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB) and patch your Kernel and CryptoLib. Then exchange/recreate the certificates of your ABAP system (Tx STRUST).

While waiting for the Kernel patch you can change the JRE security settings used for the cloud connector (NOT RECOMMENDED - just for testing on development systems!):

Open the file .../jre/lib/security/java.security and check the parameters
jdk.certpath.disabledAlgorithms
jdk.tls.disabledAlgorithms

Remove the algorithm mentioned in the log, e.g.: 

Algorithm constraints check failed on signature algorithm: MD5withRSA 

 

Restart your cloud connector.

Unable to generate authorization token for user XXX on system YYY.


Check the cloud connector log file ljs_trace.log
+0100#ERROR#com.sap.core.connectivity.protocol.http.handlers.HttpAuthenticationHandler#tunnel-client-4-2#0xd2740796#
Unable to generate authorization token java.lang.IllegalStateException: The variable 'login_name' needed for object CN is not available in context.

 

Some attribute used in the Subject Pattern for the short-lived certificate is not available.

Change the pattern is the cloud connector configuration



 

Or change the configuration of your Trusted Identity Provider in the Cloud Cockpit:



 

 

Will be updated after my next funny hours with this cool stuff ;)!

 

Have fun,
Domi
13 Comments
pjcools
Active Contributor
0 Kudos
Thanks for sharing dominik.bigl2 - nice idea - as there can be a large number of reasons why Principal Propagation does not work. Particularly interested in this ICM parameter

icm/trusted_reverse_proxy_<x>


as I have not used this previously but still managed to get PP working. Any idea what the normal values should be and what this actually does?

Thanks again!

Phil Cooley
Domi
Active Contributor
Hi phil.cooley

Thank you!

icm/trusted_reverse_proxy_<x> was introduced with Note 2025899 to support multiple trusted proxies. It's also described in https://blogs.sap.com/2017/06/22/how-to-guide-principal-propagation-in-an-https-scenario/ by michael.vancutsem

 

regards

Domi

 
pjcools
Active Contributor
0 Kudos
OK, thanks dominik.bigl2 - will check both of those references out. I have read Michael's blog a few times but have just noticed the additional reference on May 2018. Read the blog before then :-).

Thanks!
MarkusTolksdorf
Product and Topic Expert
Product and Topic Expert
0 Kudos
 

Hi Domi,

as soon as one entry for icm/trusted_reverse_proxy_<x> is present, both icm/HTTPS/trust_client_with_subject and icm/HTTPS/trust_client_with_issuer will be ignored. That might have been a reason why you could not make it work with the latter two. From content perspective, you would have added the very same values.

Best regards,
Markus
0 Kudos
Hi

 

I am wondering about this parameter icm/trusted_reverse_proxy_<x>. I have tried it but after that my connection from Cloud to On-premise is not reacheable. So I had to remove it again.

Should we remove the parameters icm/HTTPS/trust_client_with_subject and icm/HTTPS/trust_client_with_issuer, if we will use icm/trusted_reverse_proxy_<x>?

 

Regards,

Florence

 

 
Yogendra_Ahuja
Explorer
0 Kudos
Hi dominik.bigl2

i am getting the same error  for

SSSLERR_SSL_ACCEPT – received a fatal TLS certificate unknown alert message from the peer

please suggest the solution you had to resolve this issue, from the provided note i did not get the exact solution.

thanks
Domi
Active Contributor
0 Kudos
Hi yogendra.ahuja2

 

For productive use it's strongly recommended to patch the CryptoLib and Kernel as described in the note!

My temporary - NOT RECOMMENDED - solution was to remove the unsupported signature algorithm (found in ljs_trace.log) from the Java configuration file java.security.

regards

Domi

 
jonasmeyer1
Explorer
0 Kudos
Hi Dominik

I was wondering about the possibilites of your last step "assertion attributes mapping" in Cloud Foundry SCP subaccounts? There is no form like in NEO subaccounts to configure the mapping.

 

All I have is the mail attribute mapping in IAS, but when I do Principal Propagation to my ERP backend, I get:

The variable 'mail' needed for object CN is not available in context

We've done PP many times with mostly NEO accounts and it always worked, Cloud Connector config was never changed.

Thank you and KR
Jonas
florian2636
Contributor
0 Kudos
Hi Dominik,

having the same issue and got stuck setting up PP between CF and ERP backend. Any help would be highly appreciated.

Best Regards,
Florian
brunonalon
Explorer
0 Kudos
I am having the same issue. "The variable 'mail' needed for object CN is not available in context".

Did you find the solution?

 

Best Regards,

Bruno
jonasmeyer1
Explorer
0 Kudos
Still fighting with CF subaccounts! IDP delivers all assertion attributes needed by the application and backend for principal propagation.

Found this note https://launchpad.support.sap.com/#/notes/0002727260

"Cloud Foundry:

In the CF environment, the user's JWT is forwarded to the Cloud Connector. Currently, it is only possible to configure one of the attributes present in the root path of the JWT.

The UAA automatically maps the following attributes from the SAML assertion to the JWT when the user authenticates on CF:

first_name -> given_name
last_name -> family_name
mail -> email
NameID -> user_name

Only the attributes on the right hand side can be configured as Subject Pattern.

Resolution

  1. Choose another attribute for CN which exists in the SAML/JWT token instead of the current one.

  2. (not valid for CF) If you want to keep the current mapping of attributes, they need to be set in the Trusted Identity Provider configuration. For this please contact with your IDP admin


"

Love it. 🙂

I wonder if this is still true, because it would mean a real mess with existing Principal propagation scenarios for multiple customers...
jonasmeyer1
Explorer
Another update, I'm getting closer:

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

"When using a subaccount in the Cloud Foundry environment: As of version 2.12.5, the Cloud Connector also offers direct access to custom variables injected in the JWT (JSON Web token) by SAP BTP Authorization & Trust Management that were taken over from a SAML assertion."

We have SCC version 2.12.0.1. So obviously there's an upgrade needed first. I can also imagine that app developers also need to get active afterwards for "custom variables injected in the JWT"...
jonasmeyer1
Explorer
Hi all, if anyone's still interested - that's how I solved it for multiple customers:

If you are freshly implementing Principal Propagation with CF only:

  • Send claim user_name from IdP

  • Define user_name as CN in Cloud Connector


If you add CF subaccounts to existing Principal Propagation with NEO:

  • Send claim user_name from IdP

  • Define user_name as CN in Cloud Connector

    • This replaces any other CN option used by NEO scenarios before (e.g. login_name), so:

    • Existing scenarios are invalidated and need a refresh by creating new sample certificate and importing it to CERTRULE (replace existing rule)




Helpful sources:

Principal Propagation with Cloud Foundry:

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

https://launchpad.support.sap.com/#/notes/2727260
Labels in this area