Whenever I am involved in the initial discovery phase of an Identity and Access Management (IAM) project, the term Single Sign-On (SSO) always comes up. SSO is often desired or a hard requirement of customers, which inevitably prompts a clarification discussion around just exactly what SSO means to them.
The customer’s definition of SSO is usually something along the lines of “customers have one set of login credentials for all of their web applications instead of a different set for each.” For example, a single “scarter” account and password can get me access to Salesforce and Google Apps versus having a separate “scarter1” account for Salesforce and then an “scarter2” account for Google Apps.
However, this interpretation of what SSO means is actually only half correct.
The Truth About SSO
To distinguish between SSO and Reduced Sign-On (RSO), we need to take the SSO method described above one step further. SSO does give users the single set of credentials to access all of their applications. However, the difference lies in how many times they actually have to log in when accessing those applications. With true SSO, a user has access to a set of applications and is only required to authenticate (i.e. log in) once, and then they can seamlessly access all applications without having to authenticate again (during a single session, such a normal work or school day).
The challenge is that there are so many variables that will alter this authentication process a user goes through, and very seldom do users actually experience true SSO. Often, they experience something called Reduced Sign-On (RSO).
When SSO Becomes RSO
An SSO experience becomes an RSO experience when one of two scenarios occur.
In the first scenario, users still have a single credential, but have to authenticate multiple times with it to access some applications. For example, if you have access to ten different applications, after you log in the first time, you can access eight of them in that seamless SSO method, without having to authenticate again. However, when you try to access the ninth or tenth application, you are prompted to log in again using the same credential.
The second scenario centers on the fact that many applications now require an additional authentication step for more security. Users are able to use true SSO to achieve the first authentication for the application, but are then be prompted for another login. For example, you attempt to access an application that is enabled for SSO and seamlessly go to it, but then must enter an SMS code that has been texted to your phone before you can access the application.
Deciding What’s Best for Your Organization
For some organizations, both of these scenarios are “SSO enough” and are a vast improvement over the the numerous credentials they previously had for their applications. However, other organizations expect the true SSO experience where users only have to log in once. This variance is why it is important to explain the differences and properly set expectations during the project discovery and planning phases.
In addition to the two scenarios described above, there are a variety of other technical and non-technical reasons why most IAM implementations result in RSO vs true SSO. These reasons include: every application has its own timeout settings, some applications don’t support the underlying technology (e.g. SAML) required to enable SSO and are integrated with other technologies (e.g. LDAP), or there could be organizational governance policies that prohibit using the same credential across all applications.
This point is important because many SSO Portal providers (i.e. IDaaS) will lead you to believe they offer true SSO solutions. While true SSO solutions can be achieved in a 100% SAML-based environment, the actual result delivered by these providers is a very limited set of applications, configured in a rigid manner, with minimal configurations available. This type of implementation is not a bad thing per se because it does meet the needs of some, such as a small startup company working completely out of the cloud.
However, most organizations quickly outgrow this model and then need another IAM solution that provides more configurations, integration capabilities with non-SAML applications, and more advanced authentication methods. For more established enterprises that are moving from an on-premise model to leveraging cloud SaaS offerings, this distributed technology model absolutely requires a full IAM solution, and the users will most likely have a hybrid SSO and RSO experience.
While there are some technical methods for providing users more of the true SSO experience, such as a form fill authentication, the reality is most IAM implementations result in the hybrid SSO and RSO model. For 99% of users and organizations, having SSO and RSO meets or exceeds their expectations, but again, it is important to have this discussion early and often to properly set expectations. This awareness allows organizations to effectively communicate what the actual user experience will be to their constituents.