SSO Logon with X.509 certificate
SSO logon with an X.509 certificate offers some benefits. In this blog, I’ll cover the main benefits, problems and attention areas when using X.509 for SSO. As a practical example the X.509 logon with NetWeaver ABAP is shown.
To access an ICM service on a NetWeaver ABAP system (NW ABAP), you can choose from a wide range of logon procedures. A common requirement is to use a user certificate: X.509. In my example I am using in the following blogs, I’ll enable X.509 based logon to the SAP WebGui for HTML ICF service.
Logging in to NW ABAP web app (WDA, UI5, OData) with a X.509 certificate is a web scenario. An HTTP client is accessing a protected resource. In NW ABAP, the web server is ICM, and ICM is handling the client certificate requests. The login itself is handled by standard user authentication in NW ABAP.
Login with X.509 is not overly complex. It helps to know the main components and flows involved in the process.
- Client certificate: X.509. Certificate that identifies a user.
- Intermediate server: Server that receives a client certificate and forwards it to NW ABAP.
- ICM: HTTPS server in NW ABAP that receives the client certificate
- NW ABAP: Server that hosts the protected web resources a user wants to access. Handles user authentication.
- PSE: Keystore in NW ABAP containing certificates of peers and CAs.
The good
Using X.509 is bullet proofed. As I like to say: it’s old technology. It’s not cool, neither is it the perfect solution for many cloud native scenarios. But it works. It’s that kind of solution that almost everyone supports. If you encounter a problem, chances are very good the problem was solved by someone else years ago. And it is secure. If not to say: it is very secure. And user friendly. Admins can automatically distribute a certificate to a user, and a browser can use it for logon without even showing a logon screen or dialog to the user.
Having X.509 logon and more modern protocols like SAML 2.0 or OpenID Connect working together is not problem at all. To log on at an IdP, you can use X.509. It’s a very good replacement for basic auth. You log on to your IdP with X.509 and then to other systems with the received tokens. For mobile solutions, this is even a best practice: distribute X.509 via MDM, log on to IdP for OpenID Connect, and then to the app services via the OIDC token. The user is not even seeing a logon screen once. The app? Uses only modern authentication, and can easily switch from OIDC to SAML, all transparent to the user.
To configure NW ABAP to support X.509 logons, follow these steps:
- Configure ICM to accept client certificates
- Add CA certificates to PSE
- Create a X.509 user certificate
- Enable users for X.509 based logon
- Test
The bad
Use of X.509 for logons comes with some drawbacks too. For instance, you cannot use it to create automatically a user in the SAP NetWeaver ABAP system. To achieve this, you should use SAML 2.0. If you need to provide additional user information like profile or groups, you cannot get this kind of information with a X.509 certificate. If you need this kind of information, I recommend using SAML 2.0.
Good UX implies to make life easier for the user. For X.509 this means that the certificate must be distributed to the user, or: the device the user is using. For browser-based logons, the user’s certificate must be available in the browser/computer key store. If the user has 2 laptops: 2 certificates must be distributed. In case the user has a mobile device, same rule applies: distribute a valid X.509 certificate to all the users’ devices. The certificates must be maintained, that is: updated / refreshed before they expire.
Certificates expire. They can be configured to be valid for years or decades, but they should be valid for at max 1 year in a production environment. The shorter the validity, the better. This means that you have to update the certificate from time to time. With an automatic process this is an easy task. In reality, its more complicated. But worth the effort.
The ugly
Validating a certificate is an important task too. Browser vendors like Google are not checking the validity of a certificate any longer. You cannot simply do the same for user logons in a corporate environment. In case a certificate was revoked, the server needs to check this and deny a logon. A certificate can be checked by OCSP or CRL. This is important as besides the expiration day, no other information is normally checked. In case the user shared the private key, or is not any longer part of the organization, the certificate does not contain this kind of information. The receiving server must check at the issuing CA if the certificate is still valid.
Using CRL or OCSP for this check is easy in an on premise environment. In the cloud this is more complicated. Most cloud providers do not check the certificate. As long as the certificate chain validates, the user is logged on. Solving this is technically possible, but not easy. For a corporate PKI, the cloud service must be able to access the on premise CA. Depending on the service, this is rarely part of the underlying design. A user with an invalid certificate is able to log on and get a valid session. You can block the user in the backend, but what if a technical user is used? Or SAML 2.0 is used to automatically create a user in the backend? This is a complex topic that needs to be validated in the security architecture: IDM to ensure the user cannot log on with X.509 as well as a working MDM solution the delete certificates from devices.
Wrap-up
With the above listed attention areas for X.509, using X.509 based logons are one of the better solutions for SSO. Don’t use basic auth. Try to use X.509 as the standard replacement for basic auth. Certificates can be used in combination with other logon procedures (OIDC, SAML, OAuth, etc.) or used in combination with an additional credential type in 2FA/MFA. Most important learning is: don’t be afraid of X.509 certificates. They are less complicated than everyone thinks and can offer a very high level of security.
9 Comments
BernwardHenkel · July 10, 2021 at 14:34
Dear Mr. Hoffmann,
read your article and have one question:
How matches the SAP System the incoming UserID, who calls an WebService via SOAP with x.509 certificate, within the table USREXTID.
I try to call the WS from asp.net but i get a “no authorisation with anonymus”…
Thanks in advance for a reply
Bernward Henkel
Tobias Hofmann · July 13, 2021 at 11:41
Hello Mr. Henkel,
the SAP system matches the user ID from the X.509 by going through the logon stack. For the ICF Node that exposes your web service the logon stack must be configured to use X.509.
You can look at the WebGui service configuration to see a sample configuration: https://www.itsfullofstars.de/2020/07/x509-based-logon-5-test/
Steve · April 4, 2023 at 17:39
Dear Tobias.
Did I understand correctly?
If I want to access via SSO my S/4HANA systems (OData, HTTPS Websites) and cloud systems, then I cannot use Kerberlos, then only X.509 Protocol is possible?
Many thanks
Tobias Hofmann · April 4, 2023 at 18:39
Hi Steve,
for Kerberos to work the involved computers must be part of the same AD and have access on the same network. That’s why in web / cloud scenarios alternatives like SAML 2.0 or OIDC are popular, and X.509. In a cloud scenario you either log on to your SAML/OIDC IdP and then via SSO to your Service Provider (like S/4HANA) or directly via a user certificate.
Normally SSO is achieved by logging on to your IdP via a user certificate, your get a SAML 2.0 or OIDC response that is used to log on to your target system / SAP system.
steve · April 5, 2023 at 12:24
Dear Tobias,
Thanks for the detailed answer.
if I have several on-premise SAP systems where I want to use Fiori and shopping catalogs and also want to access SAP BTP applications, for example.
Which SSO deployment would be most suitable for me?
I still don’t get it.
Thanks very much
best regards
Mi · April 12, 2023 at 12:37
Hello Tobias,
We have multiple users for one user in each client. In other words, a user has different IDs in a client.
How can we realize the SSO in this szenario?
Thanks very much
Best Regards
Tobias Hofmann · April 20, 2023 at 08:14
Hi,
yes, this is possible. You’ll have to adjust the mapping rule from X.509 -> SAP user.
Herman · May 23, 2023 at 10:42
Hello Mr Hoffmann,
If no secure login server is to be used for x.509 or Kerberos, how can the certificates be distributed to clients, renewed or replaced
Thank you
Regards
Thank you
Regards
Tobias Hofmann · May 24, 2023 at 08:57
Herman,
depends on what you use to manage your clients (mobile, laptop, computer). For instance, Microsoft offers tools to manage users and their certificates. But how this is done depends on your organization.