Comment by Nextgrid | Hacker News Reader

Comment by Nextgrid | Hacker News Reader

Parent Full thread

The sad part is that we have an OS-managed standard for SSO called Kerberos, successfully used as part of Microsoft Active Directory, and for which most mainstream OSes still include support. This allows any application on your machine to inherit that auth without ever seeing a single login screen.

While it can't easily be used cross-companies (and thus why SAML/OIDC exists), it's perfect for internal company infrastructure, and SAML/OIDC can still be handled somewhat seamlessly by having a minimal service that verifies your Kerberos identity and immediately dispatches you back to whatever third-party service you wanted to authenticate to, with no intermediate login pages or even any kind of UI (this service doesn't need UI because your authentication is managed via Kerberos for which your OS provides the UI).

The problem is that you can't make money (nor "growth & engagement") off stable, battle-tested stuff that already exists and happily works in the background, so Okta/etc shareholders need to peddle worse solutions that waste everyone's time and processing power.

Kerberos relies on line of sight to the TGS. In the '90s and '00s, this was common place. As of COVID, less so.

Kerberos is also difficult to administer and secure (Golden Ticket?). Kerberos also requires the target service be a member of the Kerberos Realm (or otherwise trusted) which again means line of sight between the service and TGS or Realm to Realm.

And then we get into the whole ticket size issue.

Kerberos is not a good candidate for web-based AuthN.

> Kerberos relies on line of sight to the TGS

Isn't this the same with any SSO provider? The SSO provider must be reachable by the end-user's browser during any authentication operation.

(in case of KB it must be reachable by the target services too, but in a server-to-server environment it's less of an issue)

> Golden Ticket

Isn't this exactly the same to let's say a session cookie of a web-based IdP?

The IdP could apply policies on its backend that bind the cookie to a given IP address, user-agent or other indicators, but can't this also be done for Kerberos tickets using a server-side middleware on every service you wish to access (since KB is internal-only, it shouldn't be that big of a deal)?

> Isn't this the same with any SSO provider?

Yes, but OAuth has one major upside: HTTPS only.

No one wants to create site-to-site VPN networks to flow Kerberos.

Isn't Kerberos explicitly designed to run over untrusted networks and not require any additional transport encryption?

You could argue that the common implementations are large piles of legacy C with questionable memory safety that could open them to exploitation by malicious actors, but that's an implementation detail rather than the protocol itself - and I believe there's at least one (mostly?) memory-safe implementation in Java called Apache Kerby.

I think "successfully bastardized" as part of their embrace, extend, extinguish campaign is more accurate.

IIRC you could make AD act as standard Kerberos+LDAP with one or two registry tweaks.

SSO can seem intimidating to someone new to authentication implementations. I think this is in part because it is a bit complicated but also because it is an inherently invisible technology which we dont need think about as users. Sign in with fb/google on the other hand is something we all see in our day to day business and have at least some kind of mental picture of how it works. We've also seen it used as authentication for otherwise poorly implemented services so we might think that "since they managed to use it, how hard can it be?". Hence, a lot of developers and product owners choose those instead of SSO.

Reply on news.ycombinator.com