In my last blog, I introduced the concept of SSO and discussed some of its benefits. I will now address some limitations of SSO and propose measures on how to work around them.
Limitations of SSO
1) Single point of failure
As all logins are consolidated through a single point with SSO, if the authentication provider or portal is unavailable, then no users can access any applications or services that have been integrated. Some may use this to argue that the potential cost to reliability heavily outweighs the convenience, as well as the security and scalability benefits gained. However, there are simple steps that can be taken in order to mitigate this.
For key applications and services that require a persistent connection, implement an alternative login mechanism. Examples of this include: integration with another identity provider or supporting the ability to directly login with a username and password to these key applications.
For other applications, or ones that do not require a persistent connection, implementing an offline mode can solve this. This offline mode can also be secured through the use of a local authentication method such as a PIN or biometrics. For even more security, you could also restrict any changes made to the above to when the user is online and logged in.
2) SSO is not secure as only one password needs to be compromised
The use of SSO means that only one ‘master’ password is needed to access all applications associated with a specific login. A common misconception is that this makes the system significantly less secure as the theft of this single password can have disastrous effects. However, most users use a variation of the same password. As stated in part 1, these variations are extremely easy to break if one password is already known, hence having slightly different passwords do not actually provide any meaningful increase in security.
In order to enhance password/ account security, Multi-Factor Authentication (MFA) can be integrated with SSO to provide an additional level of security, ensuring that hackers are not able to login with just the compromised password.
3) SSO directly undermines access control
SSO only provides a mechanism for authentication and there are other factors to consider alongside it. For example, just because someone should be able to login to a certain system does not mean that they should be able to access all resources on it. As with a lot of ideas in technology, the integration of SSO is not exclusive and can be implemented into a framework that also considers fine grained access control, appropriate privileges, etc.
Implementation of SSO
I have covered the advantages, limitations, and workarounds for limitations for SSO. If you have decided to implement SSO, here are few points that will help your transition easier.
1) Decide on the scope of the framework
First decide what applications and services you want integrated with SSO. Every business has different requirements that depends on their size, main service provided, internal infrastructure, and so on. For example, the applications needed by a corporate banking entity will differ from a large clothing retailer. Also, consider if applications can be integrated with SSO, and if not, whether it is on the supplier’s roadmap.
2) Decide on the configuration used
Next, decide on the protocol that will underpin your SSO framework. Two of the most common configurations used for SSO are Kerberos and SAML.
Kerberos (named after Hades’ three-headed guard dog) is an authentication protocol that allows entities to securely prove their identities to one another over an insecure network. Put simply, Kerberos works by having parties pass special messages known as tickets to verify each other. Sensitive information such as credentials are not passed around in these tickets, instead all verifications are done locally.
SAML on the other hand provides a standard framework in which authentication data can be passed between different parties. SAML works like a referral system. Although there are minor technical specifics that change across different implementations, this framework essentially works in two parts. The user will first authenticate with an identity provider (IdP), who will provide the user a token that the user can use as proof that their identity has been verified. The user will then provide this proof to any application that challenges the user’s identity.
3) Decide on your Identity Provider (IdP)
Finally, you need to decide on an identity provider. An identity provider is the party that’s responsible for authenticating your user. This can either be done locally (e.g. ADFS) or by using a third party on the cloud (e.g. Okta, Auth0 etc.). When evaluating a third party IdP, you should consider the scalability of their services as well as their compatibility with your chosen configuration.
If you are a large business or are currently experiencing increased growth, I suggest that you consult with your local system administrator on integrating SSO with your current setup, before it becomes unmanageable. Although the limitations of SSO seem quite severe, this is only an impression formed by those who are unacquainted with the workarounds, which we have provided. We at Convene support SSO integration in our product as we recognise the scalability and savings that it can provide.
You can access part 1 of this article here.