JeliaWhat it is
Single sign-on means your people log in once, to one identity provider, and every application trusts that login. Behind the scenes it is a handful of standard protocols: OIDC for modern web apps, SAML for most commercial software, LDAP for older tools that want a directory to check passwords against.
The hard part is never the protocols. It is the applications that support none of them, the local admin accounts nobody remembers, and getting the whole thing in place without locking everyone out on a Monday morning.
Why it matters
Without one identity, every application keeps its own list of users. That has predictable consequences:
- Offboarding misses things. Someone leaves, their email is switched off, and their account on the wiki, the monitoring tool and the old file server keeps working.
- Passwords multiply. People reuse them, write them down, or share one admin login across a team.
- Multi-factor is patchy. It is on where the vendor made it easy and off where it mattered.
- Nobody can answer "who has access to what" without logging into every system one at a time.
Each of these is a quiet risk until an auditor, an insurer or an incident asks the question.
How I do it
- List every application and how it authenticates. Native OIDC, SAML, LDAP, local accounts only, or nothing at all. This list usually surprises people.
- Pick the right method for each. OIDC where it is supported, SAML where that is what the vendor offers, LDAP for the older tools, and an authenticating forward-proxy in front of anything that speaks none of them.
- Model groups and roles once. Access is granted by group membership in the identity provider, not by hand in each application.
- Set the multi-factor policy centrally. One rule, applied everywhere, with stronger requirements for admin access.
- Roll out in stages. A pilot group first, then by application. Each one keeps a documented emergency account so a fault in the identity provider does not lock you out.
- Test offboarding. Disable a test user in one place and prove they are out of everything. That test is the definition of done.
What you get
- Every application behind one login, with the method used for each written down.
- Group-based access you can read and change in one place.
- Multi-factor applied consistently, not application by application.
- An offboarding procedure that is one step, and a record that it was tested.
- A runbook for the identity provider itself: how it is backed up, how it is upgraded, and how to get in when it is not working.
In my own estate
Everything on this site's estate sits behind one identity, run on Authentik. It speaks OIDC, SAML and LDAP, and an authenticating forward-proxy sits in front of the applications that have no single sign-on of their own. File sync, webmail, chat, monitoring and the rest all use the same login. There is one place to add a person and one place to remove them.
Questions people ask
We already use a cloud identity provider. Do we need to replace it?
Usually not. If you already have one that works and you are paying for it, the job is to connect everything else to it. I recommend a self-hosted provider only where it actually suits you.
What about the application that only has local accounts?
That is what the forward-proxy is for. Nobody reaches the application until they have logged in through the identity provider. Its own accounts become a second gate rather than the only one.
What happens if the identity provider goes down?
Logins stop, which is why it is monitored and backed up like any other critical system, and why each application keeps a documented emergency account. That plan is written before go-live, not after the first outage.
Will people notice the change?
They will notice one login screen instead of several. The rollout is staged so that nobody's first experience of it is being locked out.