What is SSO?
SSO stands for single sign-on. The dream of SSO is that you sign-in once, then you can access websites without creating more accounts, new passwords and, confirming emails. It makes things simpler, easier, and more secure.
Why is it so complex?
SSO just refers to the outcome, not how to do it, or the underlying technology. The two major standards are SAML and OpenID Connect (OIDC) these provide the common language for different services and systems to talk to, and understand each other. They’re very flexible to support many different authentication scenarios, this is the first issue, understanding what the scenario is, and how to describe it. For example Offline authentication is the term used for authenticating an application without a person, it kinda makes sense, not obvious though.
You are signed into Microsoft Office365 at your company, in this case Microsoft would be called the Identity Provider (IdP) it knows your name and that you’re signed in. You then try to access a website using SSO e.g. Filtered. Filtered will ask Microsoft if you’re signed in and what your name is. Microsoft being security conscious won’t just give that information to Filtered first it will ask your permission for Filtered to see it. You click ok, you’re now logged into Filtered 🎉.
The first snag is most of companies won’t allow you to give permission to Filtered to access your name for security reasons, in this case we will need permission to be granted by a company administrator. In a 100k+ person company, finding this person, getting the right forms filled, and permissions granted is hard.
Where things get tricky
In this scenario Filtered is the the client and Microsoft is the IdP. Lots of authentication services e.g. Okta, Keycloak, Azure Active Directory can act as both an IdP and a client. This is where it gets confusing, you might have signed into Microsoft but it is a client of another IdP say Okta 🤯 also lots of companies will have many different applications and each one will have it’s own Microsoft authentication service, which could be being used as an IdP or a client, and that’s just for a single service like Microsoft Azure Active Directory.
Google, Facebook, GitHub, OneLogin can all also act as IdPs providing one or more IdPs, each with slight differences in how they’re configured. For these giants most authentication services make it easy to connect. However not everything is supported out of the box, if it’s not then we’re back to writing a custom SAML or OIDC workflow to integrate, which requires getting permissions, configurations and tokens from IT and security teams for whom this is a very infrequent job.
Who controls access?
The next question is who decides who has access to Filtered. Once Microsoft comes back saying you’re signed in, we will check whether you have permission to access Filtered, if not you’ll see an permission denied page. However in some companies it is a hard requirement that they manage access groups. So in addition to your name and if you’re signed in Microsoft can also tell us what groups you belongs to say
filtered_admins we would then need to write code to check and read those groups, to confirm your company has given you permission to access Filtered. What happens if we don’t get the groups we’re expecting back? It gets hard quickly.
SSO and user authentication is often not well understood inside companies. Once it's setup there's no reason to touch it so administrators aren't familiar with it. There's similar problems in airplane interface design, if there's a manual emergency process but a pilot never has to use it, they'll forget how to do it when it matters. Getting SSO working often requires lots of debugging through a keyhole to try and understand a companies configuration, this is fundamentally why a lot of companies charge for SSO. It could/should be simple, but rarely is for large security conscious companies. If SSO is a pre-requisite to close a deal, then as a supplier you're on the hook to get SSO working, even if it's not in your control to fix.
Can’t you just buy something in, this must be a solved problem?
Yes, and no. Most services are billed on the seat, we still run some products that have many active users, which would very quickly eat up our margins if we paid per head. They also don’t fundamentally simplify the problem space which is there are many different services that support many different configurations. Paying for a SaaS system doesn’t change this, it gives a nicer interface, and a few more off the shelf integrations than you get with a common open source tool like Keycloak, but most crucially professional support.
If you're having SSO problems drop me an email to chat about how I can help