SAP Single Sign-On Insider Tips – Volume #5

14. May 201914. May 2020 SAP Single Sign-On Carsten Olt

Welcome to volume #5 of our “SSO Insider Tips” blog series. This blog is written in the documentation style and is about a topic that occurs now and then. It exemplifies the systematically excluded possible solutions for our customer and ends with a conclusion, taking the existing customer environment and requirements into account.

The Mission

Recently, we had an exciting challenge to master. Our customer had an existing PKI and was already using certificates for Non-SAP applications. The intended implementation of SAP Single Sign-On 3.0 should be based on X.509 certificates and the component SAP Secure Login Serverhad to be operated as a subordinated issuing certification authority (CA) – limited to issue user certificates from type client authentication for the use case SAP SSO. It was not allowed for the SLS to issue other types of certificates.

With this configuration, the SLS is not operating its own Root CA but instead is part of the certificate chainup to the existing company root CA. While from a security perspective we totally agreed on this decision, it has brought with it some implications that became apparent on a later stage. At this point in time, the PKI and Security staff had given security specifications but did not inform us that client authentication certificates already being used elsewhere.

The problem arose that (after Secure Login Client certificate enrollment succeeded) every Windows and SAP user now had at leasttwo possible matching certificatesof type Client Authentication in the certificate store. Thus, both could be used to mutually authenticate to appropriately configured SAP or non-SAP systems. As a result, a selection dialog is displayed on the client browser in which the SAP user had to manually select and confirm the correct certificate for SAP SSO.

Mission Objective

Avoid selection dialog at all costs. Evaluation of the technical possibilities to reach the mission goal. Decision of the measures to be implemented in the context of a conclusion.

Situation

The users of the company should log in to SAP with a TLS client certificate. In the future, a ten-hour valid user certificate will be used for this, which is issued by the SAP Secure Login Server (SLS) Sub CAespecially for this application and is automatically distributed to all users.

Users also have another certificate issued from the Company Enterprise Sub CA. Due to its requirements, this certificate contains all the required properties for a TLS client authentication, in particular, the Extended Key Usage (EKU) “Client Authentication”. The issuer of both the
SAP SLS Sub CAand the Company Enterprise Sub CAis the Company Group Root CA (in between there was also a Policy CA).

For the client, this situation results in a usability problem. From the Browsers perspective, both certificates are considered as valid TLS client authentication certificates. Therefore, a selection dialog appears. To make matters worse, the two certificates in the selection dialog are difficult to distinguish. If the user selects the wrong certificate the authentication will not succeed and ends up with a normal “basic authentication” dialog

Technical basics of certificate selection and selection dialog

RFC 5246, Section 7.4.4 describes client-side authentication in TLS. There is also an extension certificate_authoritiesdescribed, with which the server can show certificates of CAs that can be used for the authentication.

These can be both, root CAs and sub-CAs. On the server side, SAP has a store of trusted certificates. It must have the full certificate chain of the client certificate in order for it to be accepted. This list is sent to the client in the certificate_authorities extension. On the client side, the browser (here Internet Explorer) checks which certificates are suitable for authentication. These are the certificates in the user’s MY store with the following properties:

The private key is available
The certificate
- is trusted
- has not expired
- is not revoked
- has been signed by a trusted CA or is in the list of trusted root CAs.
The certificate has the Extended Key Usage “Client Authentication” or “All Purposes” or no Extended Key Usage
One of the valid certificate chains contains one of the certificates proposed by the server

Now, none, one or more certificates can meet these requirements. What does the browser do in which case?

With no valid certificate, he does not send any to the server. This can suggest another authentication method.
If the certificate is valid, the browser authenticates itself to this certificate without further request if it is configured accordingly.
For several valid certificates, a selection dialog always appears for the user – which in fact was the issue we are talking about.

Excluded Solutions

Due to various reasons, we could not implement some possible solutions – these are briefly shown and described below.

Remove CA trust

The Company Group Root CA should be removed from SAP. This was not accepted by SAP on the server side. Even a setting with which SAP does not send the DN of the root CA certificate in the TLS handshake is not supported by SAP.

There are ways to get rid of unwanted Root or Sub CAs or even the trust to the own PKI (deselect the checkbox “Trust issuer certificate”) however, here other use cases required the existing configuration and thus we weren’t able to modify the trust settings. In addition, it should be mentioned, there are significant SAP release-related differences in the area of trust and certificate management.

Use friendly names for user certificates

Friendly Names, such as “SAP Authentication” and “Network Authentication,” can be assigned to certificates to make the user’s choice easier. Nevertheless, the users would have to click on numerous selection dialogs, the actual problem itself will not be solved.

Client-side filtering

The browser (here Internet Explorer) could check with a list which certificate is appropriate for which URL. However, Internet Explorer does not support settings to somehow filter the certificates.

Apparently, Internet Explorer offers no settings in this environment, while some other browsers do. If one can provide a solution for this, we would be very grateful for hints.

Private Key Permissions

It is possible to assign permissions to private keys located in the MY store of the machine (not the user). Thus, certain “processes” can be excluded from using the key. You could also transfer the certificates to the machine store and grant the user rights to the private key. That does not help as the Internet Explorer runs in the context of the user and so the same rights must be assigned for both certificates.

Different certificate properties

The existing certificate from the Company Enterprise Sub CA could be changed so that it is no longer usable for TLS client authentication. However, the certificate requirements for the main application use-case regarding filtering were identical to TLS client authentication. In addition, this is often not feasible since initially, all previously distributed certificates would have to be replaced with the new, under certain circumstances, a fairly large and often unmanageable effort. So this option was out of the game too.

TLS 1.3

The TLS 1.3 standard was released in August 2018. In RFC 8446, Section 4.2.5, it specifies a method for accurately selecting a client certificate. Using OID filters would be a very elegant solution to the problem. Many implementations already support TLS 1.3, but it was unclear whether SAP was one of them. Even so, it is unlikely that every SAP NetWeaver release (ICM) already supports those new extensions. Besides the web server, the browser would also need to support TLS 1.3.

At the time of writing this blog article and according to SAP Note 2765639, currently NetWeaver AS ABAP does not implement TLS v1.3.

Conclusion

While in other situations, we were able to solve similar issues by removing the trust directly on certain SAP systems (STRUST), we were unable to implement this in the specific case.

For these reasons, setting up another Root CA for SAP – in parallel to the existing one – seemed to be the best solution, which was finally implemented after consultation with the IT security department and the PKI team of the customer.

Author
Recent Posts

Carsten Olt

Managing SAP Security Consultant | SAP Trainer Secure Authentication | SSO | Cloud Security Services at Xiting GmbH

Carsten Olt has been working as a Managing SAP Security Consultant since 2016, responsible for Secure Authentication & SSO and SAP Cloud Security Services at Xiting in Germany. As a member of the IAM team, he is also a team leader who conveys the company's goals and strategies to employees and has organizational responsibility.

With a security-minded approach, Carsten has international project and IT security experience in many industries. He has been working in IT-Security since 2001, specializing in SAP security since 2010. He is a subject matter expert for SAP Single Sign-On 3.0 and a trainer for the WDESSO course. His current focus is on supporting customers in solving authentication and security challenges within hybrid SAP landscapes, as well as designing and implementing holistic authentication concepts. Carsten is an ISACA CISA and a former MCP and RHCE with an ISP background, and he looks at security from different angles. He also translates between SAP and IT security vocabulary.

Carsten has in-depth experience in multi-vendor architectures and MSFT/Azure components, dealing with all the requirements concerning SAML 2.0, OAuth, OpenID Connect, SCIM, X.509 CBA & PKI, MFA, SAP SSO, and Secure Network Communications, Kerberos/SPNEGO, data security and encryption, as well as digital signatures.

Carsten is experienced in SAP on-premises components such as S/4HANA, ABAP, and Java, as well as security solutions like SSO 3.0. Since 2019, he has focused on SAP-Cloudified environments, specifically the SAP Cloud Identity Services and SAP BTP, as well as SaaS integrations concerning IAM. He deals with hybrid SAP security in conjunction with Azure Active Directory, ADDS, ADFS, ADCS, Reverse Proxies/WAF, SAP Web Dispatcher, SAP Cloud Connector, third-party products, and infrastructure components.

	+41 43 422 8803 [email protected]
	+49 7656 8999 002 [email protected]
	+1 855 594 84 64 [email protected]
	+44 1454 838 785 [email protected]