SAP Single Sign-On 3.0 – Secure Login Server REST API
The new Secure Login Server version of SAP Single Sign-On 3.0 comes with a new REST based X.509 certificate enrollment protocol. It allows other SAP products, third party developers, and customers to develop and implement their own “Secure Login” clients, using the full range of authentication, user mapping, and certificate configuration functionality of Secure Login Server.
What’s the point?
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.
All these SAP made clients use Secure Login Server´s REST API. Now we decided to open this API to our customers.
More details, please!
All you need to develop your own client is available on most modern operating systems, be it server, desktop, or mobile. Use your favourite programming language, like C++, Swift, NodeJS, or Java.
Of course you are responsible for the secure implementation. This includes private key generation and storage, and also the secure communication with Secure Login Server. A few security parameters will be checked there: The private key type and length, the consistency of the certificate signing request, and the TLS protocol version and cipher suite strength. Other important details are up to your implementation and operating system, like protection of your private key, sharing permissions with local applications, and update strategies to avoid unexpected expiration.
The following steps cover the enrollment of a client certificate in general:
- Configure the Secure Login Server client profile URL.
- Add the TLS root CA certificate in your local trust store.
- Send your initialization request to Secure Login Server, including your desired certificate subject name.
- The Secure Login Server initialization response contains profile information like RSA key length and UI view information for user authentication.
- Create a fresh RSA key pair with the requested length. You can do this in a different thread, as it may take some time.
- If user authentication was requested, show some nice UI view and take over the received labels.
- Send an authentication request to Secure Login Server.
- The Secure Login Server authentication response contains success or error information you may present to the user.
- If another authentication is requested, go back to step 6.
- If authentication was completed, you have received all names (subject name, subject alternative names) and other extensions that must appear in your certificate signing request.
- Send the certificate signing request – a PKCS#10 blob, signed with your new RSA private key – to Secure Login Server.
- If Secure Login Server accepts your signing request, it will return with a certification response – which is a PKCS#7 blob with your new certificate plus all issuer certificates.
- Now import all certificates into the relevant local stores.
- That´s it. You should be able to use your certificate now, e.g. for single sign-on into SAP backends that allow TLS Client Authentication.
You may wonder why the client has to deal with desired and requested certificate names and extensions. Right, this is not required as long as Secure Login Server is using internal CAs. But if a Remote CA is used, all user name mapping and certificate template knowledge of Secure Login Server gets lost. This way, it is at least sent to the Remote CA inside a signed blob. However, it´s up to the CA if such information is taken over or ignored.
More about this in my blog SAP Single Sign-On 3.0 – Secure Login Server with Enterprise PKI.
Further technical specifications of the REST protocol and its JSON and FORM elements will be published soon.
One picture, please.