Three examples of SSO gone wrong
Single Sign-On (SSO) allows a user to authenticate once and sign in to various applications. SSO is great; it makes the web more secure by reducing the risk of someone stealing credentials, as users enter them only once. However, SSO also introduces new risks that too few people understand.
Implementing SSO correctly is very difficult. The protocols involved are complex, and the concepts are abstract. It requires serious study to gain a thorough understanding of SSO.
Few organizations employ developers who are qualified to implement SSO for them; nevertheless, they are assigned with the task. As a result, there are many shaky implementations out there. This article outlines three things that tend to go wrong in many implementations:
- Delegating authentication means more users can sign in than you have realised!
- Consolidating identities may lead to data leaks!
- Not knowing the impact of incidents due to insufficient logging
1.) Delegating authentication means more users can sign in than you have realised!
In many cases, in the initial implementation, more users can sign in than intended.
With Single Sign-On, authentication is delegated, meaning you are not in control of who signs in.
Most organizations fail to understand that, in contrast to traditional log-in pages, SSO is designed to authenticate people, not to authorize them.
How a Saas-vendor accidentally granted access to their clients’ clients
An example of this going wrong is an organization that provides software as a service to its customers. They federated with their clients’ corporate network on Azure, allowing their employees to use their services.
What they had failed to realise is that their customer also had the ability to federate with their clients’ corporate networks, allowing the clients to sign in and use the services too. The situation is depicted in the following diagram:
Prefer granting access over denying it
When the responsibility of authentication is delegated to a third, you need to account for it. Assume a user who has been authenticated by a third party is by default not authenticated.
Federating only is not enough. Be very specific about who is granted access. Do so by creating specific policies which may seem obvious. In this case, it was accurate to grant access to a range of departments only.
2.) Consolidating identities may lead to data leaks!
In many applications, accounts from different sources are merged into one account. This is a delegate process that’s error prone. If done incorrectly, users can see each others data. Technically speaking, that’s a data leak.
Many organisations refer to consolidating accounts as deduplicating accounts. This is done by defining rules. If an account has the same name and the same e-mail adres, they’re probably the same person. Especially in exceptional cases, such heuristics lead to problems.
How merging accounts led to users seeing each others data
A banking application had four sources where users from where users could sign in. All these accounts provided a claim called PersonId. The organisation had defined heuristics that accounts with similar names and with the same PersonId should be merged into one account.
But in some cases, people had a common first and lastname and the PersonId was left blank. So, by accident, different people with the same name saw each others financial data:
Think twice about deduplicating accounts
Deduplicating accounts may seem efficient. But it introduces serious risk. The best way to avoid that risk is by not deduplicating accounts.
Test deduplication rules thoroughly
When you do choose to deduplicate accounts, it goes without saying that the heuristics need to be thoroughly tested.
3.) Not knowing the impact of incidents due to insufficient logging
Many organisations choose not to log any personal identifiable data, or anything at all, because they think they’ll violate the European privacy act when they do. This often results in uncomfortable situations when security-related problems occur.
When, for example, a data leak is reported and the logs do not contain enough information to determine the scope of the leak, an organisation must assume the worst. This means an organisations must, in some cases, inform all their customers of the data leak.
Log, but log responsibly
Logging is important. You need diagnostic information to determine the impact of a problem.
Logging Personal Identifiable Information (PII) is not illegal. On the other hand, you cannot just log it somewhere either. Logging PII requires defining the appropriate GDPR-compliant processes, proper documentation, and it requires writing log-entries correctly.
Conclusion
Don’t think lightly about implementing SSO. The authentication concepts that apply with SSO are fundamentally different from tradition authentication methods. Mistakes are easily made.
Various organisations underestimated implementing SSO. Research the concepts and protocols thoroughly, before implementing it, and preferably, hire an expert to do it for you!
