I’m going to pick up where I left off in my cybersecurity myth-busting series. Of the myths I’ve written about already – users hate MFA and reverse proxies are bad – I’d have to say the myths around single sign-on (SSO) are way more common.
We could probably write an entirely different series just on the myths of SSO alone! The common mistake I see being made is when companies assume modern federation is enough when they start to integrate SSO.
So what exactly is federation and what does it have to do with SSO? SSO is the concept of authenticating to a single place that can then perform access control and authentication to other places. Sign-in once… and get access to other target systems without being forced to authenticate again. Nope, this isn’t a new concept. In fact, have you ever heard of Kerberos? Not the three-headed guard dog of Hades… the authentication protocol common to Windows networks. In most corporate environments, logging into a workstation is enough to then authenticate to other secure targets simply by generating ‘Kerberos’ tickets that are sent from the user’s PC to the target they are trying to access. This is actually SSO in action and it’s been around for a while! The issue with this type of authentication, and many others, is that they are not compatible with target systems that don’t understand it. To solve this problem, people much smarter than me created authentication methods based on standards that were platform and technology independent.
Modern federation technologies include protocols like WS-Federation, SAML, OAuth or OpenID Connect (OIDC). Using these methods, a target system typically requests the user’s identity from an identity provider (IdP) and receives a digitally signed response that contains the user’s identity and other important data like user attributes or even information on what the user is allowed to do. Given the user has already authenticated to the IdP mentioned above… this all happens without the user being forced to login with every request. SSO in action! This type of federation is not only the best approach to secure our sites and APIs, it is clearly the predominate technology in use today on the web. So, how could making a decision to go with modern federation be a bad idea? To be clear, it isn’t… however, choosing an SSO provider that only provides SSO is the mistake you need to avoid.
The Goals of SSO
I often explain the goals of SSO with the simple example of Yin-Yang. The almost universal goals of SSO for security professionals typically come down to one of two things. On the one hand (the Yin) we want to make sure our users are happy and that they are not constantly bothered by authenticating over and over again. Not only is that a big enough nuisance on its own, but add a proliferation of user ID’s and passwords that we need to remember, and the additional MFA challenge here and there, and we might end up spending a good bit of our day just authenticating alone. A happy workforce is a productive workforce and if we can make our users happy by providing a streamlined SSO experience then we’re taking a step in the right direction.
The Yang of SSO is more near and dear to my heart, it’s the security aspect! Without having a modern web access management strategy in place it’s going to be a struggle to meet the requirements placed on us by the security teams, auditors, and compliance reviews. You see, when you have a single place that can control access to all applications, not only can you audit and control every access, but you even have the ability to disable access to every application in your inventory with a single click. The security implications of an SSO system simply cannot be understated.
Your systems aren’t all federated. With that statement alone, I could probably wrap up this post and you’ll see why modern federation isn’t enough. But alas, let’s jump into reality.
Most of us are dealing with a mixed bag of applications. Some are federated, some use form-fill (where you enter a user ID and password), others use either basic authentication or some form of Kerberos.
While it’s true that the world is indeed moving towards the healthy goal of federation, the simple fact is that has not happened yet. In a recent conversation with a company that has moved to the cloud for 100 percent of their application (yes, really…. 100 percent), I asked for an estimate on the number of applications they were using that were federated. The response was surprising; this company had only 25-35 percent of their cloud based applications configured for federation. How was this possible!
While most companies only leverage cloud-based applications that support federation, we saw here that with 100 percent cloud based ecosystem, this company was still faced with the challenge of a truly mixed bag of authentication types. An SSO solution that only supports modern federation would not only be totally inadequate for this customer’s users, but would also fail dramatically in reaching their security goals.
To put it simply, if you are preparing for a move to SSO enable your environment, or, if you have already done so, take a long hard look at your application diversity. I’m confident you’ll find many if not the majority of your applications simply won’t understand modern federation. Without having an SSO solution in place that gives you complete coverage of all applications, regardless of authentication type, you are not only doing your users a disservice, but putting the organization at risk too.
Modern federation is enough? This myth is busted