Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
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.


Example Scenario

Preconditions:

  • The SAP Cloud Platform application is authenticated with SAML, in HTTP destination Principal Propagation is set.
  • 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.

SAML Token validation

Look for the received SAML token which contains the logged in user ID on SAP Cloud Platform. The SAML token attributes are logged, in this example the login name of the user is ONPREMUSER: 

#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: [ONPREMUSER]
    Encrypted: false
    Name: mail
    Format: urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified
    Values: [onpremuser.abap@example.backend.de]
    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
SAML Token validation - SSO token validation failed, issuer not trusted

The SAML 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: ONPREMUSER (authentication method: SAML2)
 [IdP=accounts.sap.com, SP=https://production/123456abcd;
  NameID=ONPREMUSER;
...

 

When SAML 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>'|

 

SAML 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 SAML 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 ONPREMUSER|
#DEBUG#com.sap.scc.security#tunnel-client-16-8#  #Generated X.509 certificate with subject CN=ONPREMUSER|

 

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 ONPREMUSER|
#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 Truste 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 asked

When the SSL/TLS handshake proceeds, the ICM should ask 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)

As the client (in this case SAP Cloud Connector) sends the client certificate when the server (in this case ICM process) is asking for it, the ICM process must be configured to ask for the client certificate.

When the ICM does not ask 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 will ask 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 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 SSL/TLS server needs to provide a list of trusted CA certificates to the client. The SSL/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 client, in this case, the SAP Cloud Connector 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 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 logs the received client certificate:

[Thr 1400] <<- SapSSLGetPeerInfo(sssl_hdl=158a220)==SAP_O_K
[Thr 1400]     out: subject  = "CN=*.example.de, O=SAP Cloud Connector, C=DE"
[Thr 1400]     out: issuer   = "CN=DDDTrust SSL CA - G42, O=TrustCenter, C=DE"
[Thr 1400]     out: cert_len = 1771
[Thr 1400]     out: cipher   = "TLS_RSA_WITH_AES128_CBC_SHA"
[Thr 1400] HttpModGetDefRules: Client certificate received: with len=1771, 
subj="CN=*.example.de, O=SAP Cloud Connector, C=DE", 
issuer="CN=DDDTrust SSL CA - G42, O=TrustCenter, C=DE", 
cipher="TLS_RSA_WITH_AES128_CBC_SHA"
[Thr 1400] HttpModGetDefRules: intermediate is trustworthy (i:s):
[Thr 1400] "CN=CN=DDDTrust SSL CA - G42, O=TrustCenter, C=DE"
[Thr 1400] HttpModGetDefRules: intermediary is trusted -> forward SSL header fields
[Thr 1400] HTTP request [7/105432/1] Accept trusted forwarded certificate (received via HTTPS with trusted certificate): subject="CN=ONPREMUSER",
issuer="CN=*.example.de, O=SAP Cloud Connector, C=DE"
[Thr 1400] HttpModGetDefRules: determined the defactions: COPY_CERTHEADER_TO_MPI COMPAT_HANDLING  (18)

 

Client Certificate is received but removed from SSL header

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

[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.

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:

How to Configure SAP Web Dispatcher to Forward SSL Certificates for X.509 Authentication

How to setup client certificate logon to AS ABAP from SAP Web Dispatcher

SAP Web Dispatcher SSL Certificate Forwarding WebDispatcherSSLCertificateForwarding_V3.pdf

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=ONPREMUSER<
N CertGetInfo: Issuer-Name >CN=SAPTrust SSL CA - G42, O=TrustCenter, C=DE<
N CertGetInfo: Validity >Validity - NotBefore: Thu Jan 22 18:01:43 2018 (180122130143Z)
N NotAfter: Thu Jan 22 19:11:43 2018 (180122141143Z)
N <
N lookup USREXTID for certificate mapping information
N GetUsrExtId: search for <DN, "CN=ONPREMUSER"> 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/

 

 

  • No labels