Introduction to SSO, Secure SSO, RSO and Common Authentication

The term Single Sign-On (“SSO”) is widely used, to refer to a desire of a user to authenticate only once and have access to all their applications without having to re-authenticate. For example, each user might have only one user id and password to remember, or one smart card or token device to use, and they use this method of authentication only once each day when they first log on to the network, and at the end of the day they log off.

The “SSO” term is sometimes misused and/or misrepresented, especially when it is being used to refer to a solution that in fact requires a user to logon more than once. For example, SSO might be mentioned when referring to a Web-based solution, but in fact if a user logs onto their workstation and has many applications which are not Web-based that require them to logon, and then they open a browser to logon to an application, and are required to authenticate again; from the users perspective they are not using SSO. Instead, a term which more accurately describes this kind of implementation is Reduced Sign-On (“RSO”).

It is possible to implement SSO using many different techniques. For example, SSO might be implemented by using a product that stores a user’s password for a specific application somewhere locally or centrally, and this password is inserted into the logon screen of the application when the user tries to logon to the application. This gives an SSO experience to the user, but is not considered the best or most secure solution, since password storage and transmission of passwords have both security and operational implications. Also, the maintenance costs for such a solution can be high. In contrast, a Secure Single Sign-On (“Secure SSO”) solution refers to an implementation where strong security is considered for both the user authentication and also for the network communications after the user has logged on. For a Secure SSO solution, cryptography is used to authenticate users so that password storage or transmission is not required, and shared secrets are setup between application components during the user log on, and then used for data integrity and confidentiality (e.g. encryption). Also, Secure SSO solutions can be extended to use non-password based user authentication technology if required.

Lastly, the term “Common Authentication” refers to the approach where a centrally managed, common user authentication server is used, and each time a user logs onto an application they are required to enter the same user id and password, which is checked against this central authentication server. Like, with SSO, the user does not have to remember many user id’s and passwords, but they are required to authenticate each time they logon to an application, so this is not the same as SSO. A Common Authentication solution can be implemented securely, or not securely – this depends on the authentication protocols supported by the common authentication server, and which are used when the user is required to authenticate.

In practice many companies desire enterprise-wide Secure SSO, but often find that they need to implement other methods of user authentication for a subset of their users/needs, e.g. some users might require Common Authentication, but using the same authentication server that is used for Secure SSO purposes, so that they can benefit from central management of user authentication.

What I have observed when working with SAP customers

I have worked with many SAP customers, helping each of them implement Secure SSO solutions, and I have noticed that very often the customer has a use case where SSO is not desirable, or not possible for all users to take advantage. They need a solution where Secure SSO can be offered to most users in the company, but something else is required to meet the needs of a subset of their users. For these users who cannot use Secure SSO, they still want to use the same secure, centrally managed authentication server (e.g. Common Authentication), and not fall back to using the less secure SAP user store managed authentication of users.

Example SSO scenario

For example, when Active Directory is used as an authentication server for users and for Secure SSO, if a user logs onto their workstation using an Active Directory domain authentication (userid+password, smart card, token device, biometric) and then they logon to SAP they do not get prompted for a user id and password since they already authenticated when they logged onto Windows. This Secure SSO example is common, easy to implement and clearly secure, but for companies who deploy such a solution, there are sometimes use cases where problems occur, and these are described in the section below:

Something else ?

In some companies, workstations are shared by some users - this is particularly common in manufacturing companies where workstations are used by factory workers, or warehouse workers. Clearly, the normal SSO or Secure SSO usage scenario is not convenient when workstations are shared because each user would have to logon to Windows using their own identity, and then they will have to find and run the applications they require, and if they want to logon to SAP they would first have to start the SAP Logon or Web browser, and when they have finished they would need to close down the applications required, log off SAP and then log off Windows so the next person can logon to the same workstation. All of this takes time with lots of mouse clicks and keyboard interaction, and for many users this extra effort is counter considered counterproductive and unnecessary. The logon to SAP on shared workstations should be quick and easy and allow a common centrally managed authentication server (e.g. Active Directory) to be used for these users as well as users who are able to benefit from Secure SSO.

When SSO is not used the workstation can stay logged onto an account and then the user can just click on a URL in browser or an entry in SAP Logon and then authenticate, and when finished they can log off SAP and the workstation is ready for the next user. The problem is if these users are made to logon using the non-SSO method, the user authentication method for these users becomes non standard and less secure, and difficult to control. What is more desirable is if the authentication of the user occurs when the user logs onto SAP is performed by using the same authentication server used for the users who are using SSO (e.g. not using shared workstations). This is where Common Authentication combined with SSO can have benefits.

Sometimes a user, e.g. an Basis Administrator will need to logon to their workstation as themselves and then logon to SAP using the same user (via Secure SSO), but occasionally they need to authenticate as a different user when logging onto SAP applications, and don't want to have to log off Windows and log onto a different Windows domain user account in order to use SSO to logon to SAP as a different user. They would instead want to logon to the SAP system and get prompted for a user id and password, and still be able to take advantage of the common authentication server, and secure communications.

Sometimes a customer wants to authenticate users who are logging in from other companies using the same authentication method that is used for company employees. This is sometimes used when business partners are logging onto a company’s systems using SAP GUI or Web browsers, and these business partners need a secure authentication experience and don't want to have multiple passwords to remember when logging on to SAP.

Solutions

You can find solutions which address these needs on SAP EcoHub, at https://ecohub.sdn.sap.com/irj/ecohub/solutions/trustbrokersecureclient and https://ecohub.sdn.sap.com/irj/ecohub/solutions/trustbrokeradapter