SAML 2.0 and SAP GUI Single Sign-On in one and the same scenario
Have you already experienced benefits such as Web single sign-on (SSO) and identity federation using Security Assertion Markup Language (SAML)? Do you know about the most common advantages of SAML? If yes, then you most probably know that SAML is an XML-based framework for user authentication, entitlement, and attribute information.
In the last decade, when all industry segments reconsidered their IT investments, focused heavily on Web solutions, and implemented their first cross-domain business processes, SAML was gaining more and more trust and supporters.
IT experts love SAML because it is secure, interoperable, easy to implement and support. But when it comes to heterogeneous landscapes, for which the IT team has to integrate large systems and applications with various old and new technologies, SAML could not be the standard of choice in all the cases.
Here SAP has a solution to offer to their customers by supporting a scenario in which the interoperable SAML assertion could be used for the issuance of a well-known X.509 client certificate and then the certificate to be used for authentication to applications such as SAP GUI that do not support SAML authentication mechanisms, but accept X.509 client certificates.
The main idea of the sample scenario is to implement SSO to the SAP AS ABAP systems, with SAP GUI as the frontend, using SAML 2.0 assertion. The SAML assertion is issued by the SAP NetWeaver Single Sign-On Identity Provider (SAP IDP) and is used for authentication to the Secure Login Server, and then the Secure Login Server issues an X.509 client certificate acceptable for authentication via the SAP GUI. This is an identity provider initiated single sign-on scenario.
The implementation of such scenarios is possible using the SAP IDP and the web-based Secure Login Web Client (SLWC) – a feature of the Secure Login Server. These components are available via the SAP NetWeaver Single Sign-On product.
The scenario includes the following steps:
- A user starts a browser
- The user authenticates at the SAP IDP. Here two cases are possible:
- Assertion is created automatically: If there is an actively running session for this user on the SAP IDP because of previous authentication request for another service provider, the user will get the new SAML 2.0 assertion for the respective service provider without additional authentication.
- Assertion is created after successful authentication to the SAP IDP: If the user has no running session at the SAP IDP, the authentication will be forced once the request for SAML 2.0 assertion is received. When the user authenticates successfully the assertion will be provided. The authentication to the SAP IDP could be basic authentication or other, for example authentication with a Kerberos token.
- A SAML 2.0 assertion for the SAP NW AS Java system is issued. (This is the system where the Secure Login Server is installed and configured.)
- The user is successfully authenticated at the SAP NW AS Java system with the SAML 2.0 assertion. A page which contains the Secure Login Web Client is loaded in the user’s browser. Secure Login Web Client generates a key-pair and issues a certificate signing request to the Secure Login Server.
- Based on the authentication at the previous step the Secure Login Server recognizes the user, issues a X.509 client certificate and returns it back to the Secure Login Web Client. The Secure Login Web Client imports the key-pair and the X.509 client certificate into the Windows Certificate Store.
- The user starts SAP GUI
- The user is authenticated automatically (through SSO) to a required SAP NetWeaver AS ABAP system using the X.509 client certificates imported in the previous step. The same X.509 client certificates can be used for Web SSO also to SAP and non-SAP systems if they do not support SAML 2.0 yet.
This scenario could be implemented also with SAML 2.0 identity providers from other vendors because SAP Secure Login Server capabilities include integration with different identity providers. However, we recommend the SAP IDP because of the competitive advantages the SAP product offers. For more information about these advantages, see Competitive advantages of SAP Identity Provider.
The SAP IDP also supports the service provider initiated single sign-on. Here the service provider will be the Secure Login Server, because the SAML 2.0 base communication for these scenarios is between the SAP IDP and the Secure Login Server. The service provider initiated single sign-on starts again from the browser but the second step is when the user requests the Secure Login Web Client, and based on this request the user is redirected to the SAP IDP for authentication. All steps afterwards are the same as with identity provider initiated single sign-on scenario, described in details above.