Single Sign On – What Does It Mean?

Here at ProofID, we’ve been working on a project with a customer to review their existing Single Sign On (SSO) setup and make recommendations about their future direction. As part of this, we’ve conducted many workshops with people from right across the organization, and during these sessions it’s become clear that Single Sign On means different things to different people, and there is no standard way of talking about the various types of SSO.

So here are some of the terms we use to describe SSO at ProofID; hopefully this may be of some use to help you think about what can be achieved with SSO.

Single sign-on

Single Sign On means that after a user has logged into the Single Sign On service, or one of the applications ‘behind’ the SSO service, they no longer need to enter their username and password to access any other applications. Typically SSO refers to ‘browser based’ applications, but in some circumstances can also extend to ‘fat clients’ – for example in many Office365 SSO deployments, SSO is also provided via the Outlook client.

By far the best approach to providing Single Sign On is to adopt a federated approach, where all authentication is essentially delegated from the application back to a central authentication source (e.g. Active Directory). There are other means of achieving SSO, such as password vaulting or form fill, but both of these approaches are questionable from a security perspective as they involve storing and transmitting user password, and also because they require full user credentials to be provisioned in all applications – particularly for SaaS applications, this may be undesirable. A further difficulty with this approach is as they tend to rely on form fill to replay credentials, they are much more ‘brittle’ than standards based federation; if the login form changes, then form-fill SSO is at risk of failing.

Simplified sign-on

This isn’t really Single Sign On at all, and means the use of a common username and password to access all applications. This is different from SSO, because with Simplified Sign On, users still need to enter their username and password to access each application, whereas under SSO this happens automatically after the user has logged into the first application. It is also worth bearing in mind that with Simplified Sign On, it is always necessary to provision a full set of user credentials (including the password) into each application, which is  arguably less secure than in a federated SSO model (see above).

Seamless single sign-on

We use it to mean a setup whereby once the use has authenticated to their workstation, they no longer need to provide any credentials to access web based applications. In many cases, this is considered to be the ideal user experience, as from a user perspective it is almost ‘no sign in’. In this scenario, authentication usually takes place via Kerberos, so the Seamless SSO experience is only possible from domain joined computers.

Single sign-on domain

We use the phrase SSO Domain to mean a set of applications which can accessed via a given SSO service. It’s a useful term in many organizations, and in particular universities, where it is not unusual for many SSO services to exist side by side. For example, most Universities will have ADFS for SSO to Office365, Shibboleth for SSO to UK Federation services, and often a third SSO service to provide SSO to other applications. The end result of this is multiple ‘pockets’ of SSO, where users get SSO to a subset of applications, but will need to sign in again to access applications in a different SSO domain. This can be confusing as a user experience, but is maintained in many organizations due to the difficulties in integrating different SSO solutions.

Unified single sign-on

We use the phrase ‘Unified SSO’ to mean a situation where a single SSO Domain covers all applications in an organization. In combination with Seamless SSO, this really is the ‘gold standard’ in terms of SSO experience, whereby the requirement for users to enter their credentials is kept to an absolute minimum.

In order to achieve secure Unified SSO in a typical modern enterprise, an SSO solution is required which has the broadest possible support for federation protocols, with a wide range of integration tools. This means that it is possible to provide federated SSO to applications which may not natively support federation, without needing to fall back to less secure methods such as password vaulting.