Skip to end of metadata
Go to start of metadata
 

Content tree


Introduction

You have configured principal propagation from SAP Cloud Platform to on-premise system, however, the principal propagation does not work, the on-premise backend system keeps sending 401 HTTP code. This wiki helps to figure out the reason and to correct the configuration.


The capabilities of single sign-on with principal propagation for SAP Cloud Platform


SAP HANA Academy – SAP Cloud Platform: Security Principal Propagation


Scenario

Preconditions:

  • The SAP Cloud Platform application is authenticated with SAML. 
  • In SAP Cloud Platform the Principal Propagation is set in the HTTP destination.
  • In SAP Cloud Connector the Principal Type is set to X.509 Certificate for the corresponding on-premise system.
  • The configuration is based on the SAP Cloud Connector online help Configure Principal Propagation to an ABAP System for HTTPS.


The SAP Cloud Connector receives the SAML token from SAP Cloud Platform and generates a short-lived X.509 client certificate. The conversion from SAML to X.509 certificate preserves only the principal information, no other SAML attributes will not be propagated.

To find the reason of the authentication error, ICM, SAP Cloud Connector and for ABAP security components need to be traced:

  • set ICM trace level to 3
  • in SAP Cloud Connector set Cloud Connector  loggers to All and set Payload Trace flag. Keep Other Loggers on Information.
  • set ABAP security trace to 2 see SAP Note 495911 or use SEC_TRACE_ANALYZER report see SAP Note 2181120 - Tracing and troubleshooting security events in HTTP communication with the AS ABAP

When the authentication fails, open SAP Cloud Connector log file, ljs_trace.log.

SSO Token validation

Look for the received assertion, it contains the logged in user ID on SAP Cloud Platform. In this example the login name of the user is P0123456

#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-16-8#0x1234abcd
#SAML2Assertion attributes received: Attributes
Name: login_name Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified Values: [P0123456] Encrypted: false
Name: mail Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified Values: [onpremsuer.abap@example.backend] Encrypted: false
Name: last_name Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified Values: [ONPREMLASTNAME] Encrypted: false
Name: first_name Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified Values: [ONPREMFIRSTNAME] Encrypted: false


SSO Token validation - SSO token validation failed, issuer not trusted

The SSO token is validated, validation logs the following entry:

#DEBUG#com.sap.security.saml2.sp.sso.AssertionValidationService#tunnel-client-16-8#0x1234abcd #SAML2Assertion successfully validated ...
#DEBUG#com.sap.security.saml2.sp.sso.Utils#tunnel-client-16-8#0x1234abcd
#Service Provider has received SAML2Assertion from Identity Provider [accounts.sap.com] that contains authentication context [urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport] which could not be found in the configuration.|  
#DEBUG#com.sap.security.saml2.sp.sso.Utils#tunnel-client-16-8#0x1234abcd #SAML2Principal successfully created: P0123456 (authentication method: SAML2)  [IdP=accounts.sap.com, SP=https://production/123456abcd; NameID=P0123456; ...


 

When SSO token validation fails, a similar entry is logged in ljst_trace.log file:

#DEBUG#com.sap.core.connectivity.tunnel.client.sso.SSOClientProcessor#tunnelclient-21-2#0x1234abcd
#SSO token validation failed. com.sap.core.connectivity.tunnel.client.sso.InvalidSSOTokenException: Unable to validate SAML2 assertion
at com.sap.core.connectivity.tunnel.saml2.SAML2TokenValidator.validateToken(SAML2TokenValidator.java:46)
...
Caused by: com.sap.security.saml2.sp.sso.exception.BadCredentialsException: The issuer of the received SAML2Assertion is not a trusted Identity Provider. There is no configuration for IdP 'https://idphost.domain.zzz/12345678-1234-1234-1234-12345678/'
at com.sap.security.saml2.sp.sso.LoginResult.throwBadCredentialException(LoginResult.java:268)
at com.sap.security.saml2.sp.sso.SAML2Authentication.validateAssertion(SAML2Authentication.java:1412)
at com.sap.core.connectivity.tunnel.saml2.SAML2TokenValidator.validateToken(SAML2TokenValidator.java:35)
... 34 more|


It happens as the IDP is not trusted by the SAP Cloud Connector, this IDP must be set a trusted IDP and must be synchronized with the affected subaccount.

In SAP Cloud Connector administration UI select the affected subaccount and perform synchronization:

When synchronization is finished this entry is logged in ljs_trace.log file with INFO severity level:

#INFO#com.sap.core.connectivity.tunnel.client.sso.TrustConfigurationServiceImpl#http-bio-8443-exec-2#          #Starting synchronization of IDP configuration for tunnel id 'account:///<subaccountID>'| #INFO#com.sap.core.connectivity.tunnel.client.sso.TrustConfigurationServiceImpl#http-bio-8443-exec-2#          #Successfully finished synchronization of IDP configuration for tunnel id 'account:///<subaccountID>'|


 

SSO Token validation - SSO token validation failed, the application is not trusted

Another reason for the validation error can be that cloud application is not trusted, the ljs_trace.log file contains a similar exception:

#DEBUG#com.sap.core.connectivity.tunnel.client.sso.SSOClientProcessor#tunnel-client-5-6#0x1234abcd
#SSO token validation failed. com.sap.core.connectivity.tunnel.client.sso.InvalidSSOTokenException: The account/application/type gwaas/gwaas/JAVA is not trusted for principal propagation!


To enable principal propagation for cloud applications maintain the trusted applications list, see SAP Note 2616408 - Principal Propagation via SAP Cloud Connector does not work - InvalidSSOTokenException

or the online help Trust Cloud Applications in the Cloud Connector.

 

Creating X.509 Certificate

When SSO token has been validated, an X.509 client certificate will be generated, in ljs_trace.log file look for this entry:

#DEBUG#com.sap.scc.security#tunnel-client-16-8#  #Generating X.509 certificate for authentication to backend|
#DEBUG#com.sap.scc.security#tunnel-client-16-8#  #Requesting token for principal P0123456|
#DEBUG#com.sap.scc.security#tunnel-client-16-8#  #Generated X.509 certificate with subject CN=P0123456|

...

#DEBUG#com.sap.core.connectivity.tunnel.client.sso.CallerPrincipalProviderImpl#tunnel-client-16-8# #Assigned principal: 'P0123456'|
#DEBUG#com.sap.core.connectivity.protocol.http.handlers.HttpAuthenticationHandler#tunnel-client-16-8#0x5ea79b06#Will use X.509 certificate for authentication to backend:

MIIFNTCCAx0CBQDlwCl9MA0GCSqGSIb3DQEB.....
P2wsz3TMTxjzojAp9GRHqa80YEEcEfx3QtU9Nw4hzgtaIE32tuneqo4dmFXE3AOJiHe5NcDDJVCPhoWxjKK3w=|

To see the content, copy the X.509 certificate ("MIIFNTCCA...KK31=") into a file, client.crt and open with a certificate decoder tool or in Windows simple double click on it. 

Note this certificate is issued by the CA certificate.

 

X.509 certificate generation fails - IllegalStateException: No CA certificate available

To create a temporary client certificate the local CA certificate is used. When the CA certificate is not present, this message is logged in the ljs_trace.log file:

#DEBUG#com.sap.scc.security#tunnel-client-5-1# #Generating X.509 certificate for authentication to backend|
#DEBUG#com.sap.scc.security#tunnel-client-5-1# #Requesting token for principal P0123456|
#ERROR#com.sap.core.connectivity.protocol.http.handlers.HttpAuthenticationHandler#tunnel-client-5-1#
#Unable to generate authorization token java.lang.IllegalStateException: No CA certificate available, which is required for supporting Principal Propagation.
at com.sap.scc.cert.CertificateGenerator.createLocalToken(CertificateGenerator.java:242)
at com.sap.scc.cert.CertificateGenerator.createToken(CertificateGenerator.java:185)
at com.sap.scc.cert.CertificateGenerator.generateToken(CertificateGenerator.java:145)
at com.sap.scc.sso.SccBackendTokenGenerator.generateToken(SccBackendTokenGenerator.java:51)


Configure the local CA Certificate, see online help page Configure a CA Certificate for Principal Propagation.


X.509 certificate generation fails - IllegalStateException: The value for the required variable CN is not available in the context

When the received SAML assertion does not contain the configured mapping attribute an IllegalStateException is thrown. For example, the CN parameter is set to ${login_name}, but the SAML assertion does not include the login name, this exception happens: 

#ERROR#com.sap.core.connectivity.protocol.http.handlers.HttpAuthenticationHandler#tunnelclient-12-2#0x1234abcd
#Unable to generate authorization token java.lang.IllegalStateException: The value for the required variable CN is not available in context.
at com.sap.scc.cert.DN.toRDN(DN.java:108)
at com.sap.scc.cert.CertificateGenerator.generateToken(CertificateGenerator.java:108)
at com.sap.scc.sso.SccBackendTokenGenerator.generateToken(SccBackendTokenGenerator.java:51)


Either the Identity Provider has to be configured to provide the login name attribute or another available SAML attribute can be configured, see the online help Configure a Subject Pattern.

 

X.509 certificate generation fails - IllegalStateException: The value for the required variable EMAIL is not available in the context

#ERROR#com.sap.core.connectivity.protocol.http.handlers.HttpAuthenticationHandler#tunnel-client-5-4#
#Unable to generate authorization token java.lang.IllegalStateException: The value for the required variable EMAIL is not available in context.


The reason and solution are described in SAP KBA 2584310 - java.lang.IllegalStateException: The value for the required variable EMAIL is not available in context. 

TLS Handshake

SSL/TLS Handshake - General SSLEngine problem

The SAP Cloud Connector tries to open the HTTPS connection to the backend system.

When the SSL/TLS server's issuer certificate is unknown, the SSL/TLS handshake fails:

#ERROR#com.sap.core.connectivity.spi.processing.OutboundConnectionErrorHandler#tunnel-client-28-1#0x1234abcd
#Internal error io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
...
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280)
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382)


In that case, the SSL/TLS server's issuer certificate needs to be added to the Trust Store of the cloud connector:

    • in cloud connector main menu choose Configuration
    • Select On Premise tab
    • In Trust Store section press add button
    • In popup windows select the public key of the backend system 

Client Certificate Authentication

Client Certificate is not requested

When the SSL/TLS handshake proceeds, the ICM has to request for the client certificate, in ICM log file (dev_icm) this entry is logged:

[Thr 1400] ->> SapSSLSessionInit(&sssl_hdl=7fffc0d677d8, role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT))
[Thr 1400] <<- SapSSLSessionInit()==SAP_O_K [Thr 1400]      in: args = "role=2 (SERVER), auth_type=1 (ASK_CLIENT_CERT)"
[Thr 1400]     out: sssl_hdl = 158a220 ... [Thr 1400]   Client Certificate available (FCPath-Len= 0)


The TLS client (SAP Cloud Connector) sends the client certificate (system certificate) in case:

  • TLS server requests for the client certificate during handshake. The ICM must be configured with VLCLIENT or icm/HTTPS/verify_client profile parameters.
  • TLS server offers the trusted CA certificate which issued the client certificate

When the ICM does not request for the client certificate, this entry is logged in ICM trace:

[Thr 1407] <<- SapSSLSessionInit()==SAP_O_K
[Thr 1407] in: args = "role=2 (SERVER), auth_type=0 (NO_CLIENT_CERT)" ...
[Thr 1407] status = "new SSL session, client cert NOT requested"


The ICM requests for client certificate with the following profile parameters:

HTTPS port configuration contains VCLIENT=1

icm/server_port_1 = PROT=HTTPS, PORT=8001, TIMEOUT=30,PROCTIMEOUT=60, VCLIENT=1

or the HTTPS port configuration does not contain VCLIENT parameter as the default value is 1:

icm/server_port_1 = PROT=HTTPS, PORT=8001, TIMEOUT=30,PROCTIMEOUT=60

The ICM process will not ask for client certificate when HTTPS port configuration contains parameter VCLIENT=0 or global ICM parameter icm/HTTPS/verify_client  is set to 0:

icm/server_port_1 = PROT=HTTPS, PORT=8001, TIMEOUT=30,PROCTIMEOUT=60,VCLIENT=0

or

icm/HTTPS/verify_client = 0

If icm/HTTPS/verify_client is set to 0, the VCLIENT=1 parameter must be added to the HTTPS port configuration:

icm/HTTPS/verify_client = 0
icm/server_port_1 = PROT=HTTPS, PORT=8001, TIMEOUT=30,PROCTIMEOUT=60, VCLIENT=1

as individual port configuration overrides the global parameter.

 

Client Certificate is requested but not received

Even though the ICM requests for a client certificate, the SAP Cloud Connector may not send the client certificate. The ICM logs that no client certificate has been received.

In case of client certificate authentication, the TLS server needs to offer a list of trusted CA certificates to the client. The TLS client then looks for a client certificate which is signed by one of the offered CA certificates. When no such client certificate can be found, the TLS client will not send the client certificate to ICM.

The offered CA certificates can be fetched from ICM with openssl tool:

$ openssl s_client -connect <backend host name>:<HTTPS port>
Acceptable client certificate CA names
/C=DE/ST=x/L=WD/O=CCC/OU=DDD/CN=hci_client_certificate
/C=DE/O=FFF-AG/CN=SSO_CA
/C=DE/L=WD/O=DDD/CN=GGGNetCA_G2
/C=DE/L=WD/O=DDD AG/CN=FFF Global Root CA
Client Certificate Types: RSA sign, ECDSA sign


In ICM trace similar entries are logged:

[Thr 1400] CCL[SSL]: Srv-000000A8: Offering 6 trusted CA(s) for client authentication:
[Thr 1400] CA <0>: CN=root CA 001, DC=aaabbbccc, DC=com
[Thr 1400] CA <1>: CN=root CA 002, DC=aaabbbccc, DC=com
[Thr 1400] CA <2>: CN=root CA 003, OU=aaabbbccc, O=dddfff, C=US
[Thr 1400] CA <3>: CN=server CA 004, O=cccddd, C=US
[Thr 1400] CA <4>: CN=server CA 005, O=eeefff, C=DE
[Thr 1400] CA <5>: CN=global CA 006, OU=certificate, O=global CA, C=US


In Linux the openssl package can be used in Windows the Git for Windows includes openssl.

 

When the SAP Cloud Connector system certificate issuer is not included in this list, it needs to be added to the CA list with STRUST transaction, see the online help Configure an ABAP System to Trust the Cloud Connector's System Certificate.

When SAP Cloud Connector sent the client certificate, the ICM log shows the received client certificate in the SSL_CLIENT_CERT HTTP header:

[Thr 1400] HTTP request (raw) [14/70000/1]:
[Thr 1400] GET /sap/opu/odata/SAP/FUNCTIONMODULE_SRV/$metadata?sap-language=ES HTTP/1.1
...
[Thr 1400] ssl_client_cert: MIIE8jCDAtYCBFSvwYAwDQYJKoZIhvcNAQELBQAwUzELMA...
...
[Thr 1400] Forwarded Client certificate: subject="CN=P0123456", issuer="CN=SCC_CA_CERT"



Client Certificate is received but removed from SSL header

When ICM does not trust the issuer, it removes the client certificate from the HTTP header:

[Thr 4740] HttpModIsReverseProxyTrustworthy: no trust relationship to intermediary specified (see documentation for parameter "icm/HTTPS/trust_client_with_issuer" or "icm/trusted_reverse_proxy")
[Thr 4740] HttpModGetDefRules: intermediary is NOT trusted -> remove SSL header fields
[
Thr 4740] HttpModGetDefRules: determined the defactions: REMOVE_SSL_HEADER COMPAT_HANDLING  (24)
[Thr 4740] HttpModHandler: remove incoming ssl header

The icm/HTTPS/trust_client_with_issuer and icm/HTTPS/trust_client_with_subject parameters need to be set, see help page Configure Principal Propagation to an ABAP System for HTTPS,

or icm/trusted_reverse_proxy_<xx> when

SAP Note 2052899 - ICM - Multiple Trusted Reverse Proxies

is implemented

Web dispatcher configuration

If there is an SAP web dispatcher in front of the backend systems, HTTPS must be used in the communication chain to send the client certificate to the backend:

SAP cloud platform - (VPN) - SAP cloud connector - (HTTPS) - SAP Web Dispatcher - (HTTPS) - ABAP ICM
Web dispatcher terminates the TLS connection

When an SAP web dispatcher exists in front of the ABAP ICM, the SAP web dispatcher must be configured to request the client certificate and offer the CA list.

Additionally, the SAP web dispatcher must forward the client certificate to the ABAP ICM.

See Wiki pages for web dispatcher configuration:

Web dispatcher does not terminate the TLS connection

In that case, the ABAP ICM needs to request for the client certificate. 

Certificate mapping 

Missing client certificate mapping

Finally, the client certificate is forwarded however the ABAP system still responds with 401 HTTP code.

Now look for the ABAP security traces, logged in dev_w* files:

N dy_signi_ext: X.509 client certificate logon with ticket request
N CertGetInfo: Subject-Name >CN=P0123456<
N CertGetInfo: Issuer-Name >CN=SCC_CA_CERT<
N CertGetInfo: Validity >Validity - NotBefore: Thu Jan 22 18:01:43 2020
N NotAfter: Thu Jan 22 19:11:43 2020
N <
N lookup USREXTID for certificate mapping information
N GetUsrExtId: search for <DN, "CN=P0123456"> in client 010 for user ""[...]
N GetUsrExtId: 0 matching USREXTID entries found
N dy_signi_ext: X.509 mapping to username failed


 In this case, there was no mapped user for this client certificate. See the online help about how to map the user Map Short-Lived Certificates to Users.

Mapping Client Certificate ST field

When the issuer certificate contains the SP field, in CERTRULE it is displayed as ST field.

SAP Note 511919 - Trust manager: Entering complex distinguished names. 

Client Certificate CN field contains a different attribute

When not the login name, but the email attribute is expected in CN field, it can be adjusted as described in the online help Configure a Subject Pattern for Principal Propagation.

 


Links

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

https://blogs.sap.com/2017/06/26/how-to-guide-troubleshooting-principal-propagation-icm-traces/

Maintaining Logon Procedures - Standard Logon Order

 

 

  • No labels