SAP Single Sign-On 3.0 SP01 – Secure Login Server with Enterprise PKI
The new Secure Login Server version of SAP Single Sign-On 3.0 enhanced its X.509 capabilities by adding support for Enterprise PKI products like Microsoft Active Directory Certificate Services or Certificate Management over CMS (CMC) based solutions.
Up to version 2.0, multiple internal or HSM based certificate authorities (CAs) were provided. With version 3.0, a “Remote CA” can be implemented as registration authority, connecting to a PKI web service. Of course, multiple of such Remote CAs can be configured.
Update: With SP01, we have extended and improved the Remote CA support. See SAP Note 2375797 – Secure Login Server 3.0 SP01 – Remote CA Configuration for the details.
What’s the point?
Secure Login Server comes with interfaces to multiple clients, like Secure Login Client and JavaScript Web Client, Certificate Lifecycle Management, SAP Mobile Platform, SAP Cloud Connector, SAP Authenticator for iOS and Android, and any REST protocol based clients developed by third parties or customers.
For all these clients, Secure Login Server offers several authentication schemes and protocols including multi-factor and risk-based authentication, client profiles, and user name mapping algorithms which are required for modelling single sign-on workflows for specific SAP or non-SAP login scenarios.
On the other hand, the existing internal PKI of an enterprise is often seen as the “holy grail of corporate security”, and security policies may even ban any other certificate issuer. The main aspects are the ownership and protection of the CA´s private keys, plus the ownership of the issued certificates database, plus the authorisation management for approvals, operators, and registration authorities.
So the consequent solution for Secure Login Server is to integrate into given PKI setups, and to add the existing SSO modelling and integration functionality.
More details, please!
Technically, a Secure Login Server Remote CA consists of three components:
Just another CA which is created in Certificate Management, it can be used by any client or application server that supports Secure Login Server enrollment protocol version 3.0.
A NetWeaver HTTPS destination, with an URL linking to the PKI´s web service and the web service´s TLS root certificate as trusted certificate view.
The corresponding registration authority authentication credentials, also configured inside the HTTPS destination. Either basic authentication with username and password or TLS client authentication with private key and certificate is possible.
The remote side, a web service provided by the Enterprise PKI, depends on the respective product. Currently, Secure Login Server 3.0 supports two types of interfaces:
- Microsoft Active Directory Certificate Service and its Certificate Authority Web Enrollment
- Microsoft Active Directory Certificate Service and its Network Device Enrollment Service
- Simple CMC with HTTPS transport, which is in fact PKCS#10 / PKCS#7
The following clients already support Secure Login Server 3.0 with Remote CAs:
- Secure Login Client 3.0
- Secure Login JavaScript Web Client 3.0
- Certificate Lifecycle Management for ABAP (SSF_CERT_ENROLL, SSF_CERT_RENEW)
- Certificate Lifecycle Management command line interface (SAPSLSCLI)
Anything else?
Although Secure Login Server is optimised for issuing short-lived end user certificates, there was never a technical limitation in the validity configuration. Customers could issue longer lived certificates, if an account locking procedure was clearly defined.
But once the certificates come from an existing PKI, revocation management based on CRLs or OCSP is also possible. All certificate extensions set by the CA can be used by the receiving parties during verification. In fact, Secure Login Server is not even aware of them, as it trusts the Enterprise PKI.
One picture, please.
Much more details, documentation, videos can be found in the SAP Help Portal pages and our SSO Community.
Great post Stephan, thanks a lot 😎
I got one question in regards to the Remote CA feature which isn’t clearly to me.
Using SLS one is able to define a custom certificate layout, same in other CAs like the supported ADCS where this is done by creating custom certificate templates. However the user mapping features in ADCS are somehow limited and not as flexible as in the SLS. The SLS has these nice little „user name mapping features“ allowing a company to include details of the authenticated End-Entity like various LDAP/AD attributes and maybe others, in oder to construct the certificate subject name or additional extensions such as the subject alternative name with a value of choice.
Given the fact one has enabled Remote CA, that means the SLS is now acting as a intermediary between the End-Entity and the signing CA e.g. ADCS. As a registration authority i understand, the SLS is still responsible to authenticate the End-Entity thus still with the unchanged feature set allowing him to enrich the received certificate request with additional information about the requester.
The CA trusts the SLS-RA, receives the „modified“ PCKCS#10 signature request from SLS, somehow wrapped inside CMS or by other means, sent from SLS to CA via enrollment web service or CMC using HTTP/TLS as a transport layer. All fine.
Now based on the CA certificate policies, certificate template design etc. the CA may be able to use the additional user name attributes part of the CSR and just signs the certificate or maybe just not, because it does not meet the policy and the request will be denied by the CAs policy module. Do you already have some experiences when it comes to those user mapping scenarios e.g. instead using the Fully Distinguished Name or Display Name as the subject of a user certificate, to use a custom CN attribute in the subject? Hope I will soon have the chance to make my first project experience with that long-awaited Remote CA feature 😉
Cheers, Colt
Hi Carsten,
the capabilities of an SLS Remote CA strongly depend on the concrete product, service, and configuration. With ADCS it is quite limited. You cannot access the full scope of the CA´s certificate templates (which is also a restriction in the current ADCS adapter we ship with SP0, it does not allow to configure the template; we plan to change this and to offer an ADCS NDES adapter).
However, it is possible to take over at least the full subject name sent in the PKCS#10 CSR. And this name can be set by SLS, using the full set of user mapping and name generation features.
Btw. SLS is not able to modify the client´s PKCS#10 request. It´s one of the new things in SSO 3.0 that SLS clients (like SLC or SAPSLSCLI) perform a name negotiation before the CSR is created on client side. That´s why Remote CA support is only provided for new SLS clients.
-- Stephan
Hi Stephan, thanks for clarifying. Makes all sense.
Regards, Colt
So just to be sure - with SP00 it is not "Certificate Enrollment Web Services" which is support but instead "Certificate Authority Web Enrollment" which is a small but nice difference!
So true. Fixed it.
Under Anything Else you discuss OCSP. If I search the SAP Single-Sign On implementation guide I only find one reference for OCSP. There is documentation related to configuring CRL, maintaining the list, and more. But with OCSP it is a dynamic call at the point you need a certificate validated. Is there a different guide for using OCSP? From the image above, is this handled outside at the JAVA layer so that a revoked certificate is not known to SSO similar to how a CAPI filter prevents certificates from being seen or consumed?
Your client side needs to support OCSP to make use of such extension. The SAP SSO clients or CCL based apps do not support OCSP yet.
A possible use case could be that a web server validates the user´s certificate, or a web browser is doing it for a server certificate.
-- Stephan
Hi Stephan,
do you know if there are any plans to support Entrust PKI ?
Uwe
Hi Uwe,
no, there are no such plans currently. AFAIK, Entrust is supporting CMP only, while we offer Simple CMC.
-- Stephan
Hi experts!
Since past week, i don´t see any more SECURE LOGIN SERVER 3.0 SP01 available for download, ¿do you know what happened?
Thanks a lot!
Hi,
we just have released SLS 3.0 SP01 PL01.
Thanks for waiting.
-- Stephan
Hello Mr. Andre,
From the installation guide it is not clear to me, where the secure login server should be installed.
Should it be deployed into some running AS Java instance?
Or it is independent self-running instance and can be installed anywhere?
Thank you
Hello,
Secure Login Server is a Java application that runs on AS JAVA. Indeed, there is no explicit mentioning in the installation guide, except https://help.sap.com/viewer/df185fd53bb645b1bd99284ee4e4a750/3.0/en-US/b8ff297db0cf42c7a76b798bb0e76823.html.
But the PAM https://support.sap.com/content/dam/launchpad/en_us/pam/pam-essentials/TIP/PAM_SSO_30.pdf is listing all supported platforms (SLS: slide 9).
-- Stephan
Thank you 🙂
Hi Stephan,
Thanks for sharing the nice blog,
We are configuring the SSO 3.0 with LDAP Authentication As I have installed the Secure login server and secure login client. but i am really not getting any idea on how to proceed,further to configure the SSO.
I really appreciate if i can get any document or any steps.
Thanks & Regards
M V Gopal
Hi M V Gopal,
Did you get any solution for your problem?
Thanks
AB
Dear Stephan,
Thanks for sharing your knowledge, really helped.
I'm also trying to integrate SLS 3.0 with an external PKI structure. I created the required HTTPS destination but somehow the ping destination test is failing with the below error message " Error during ping operation: Error while silently connecting: org.w3c.www.protocol.http.HttpException: Connection Reset".
P/S- I'm able to access the PKI Web Service URL with the authenticated domain user and used the same user in the HTTPS destination as well.
Please advise..
Thanks in advance !!
Hello Stephan
We are trying to connect SAP JAVA with SSO 3.0 with X509
We have completed the SSL setup with root certs of secure login server
Is there any specific steps we need to perform for user mapping in order to achieve single signon for JAVA