3 ms·
> 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 an
by Nextgrid 3y ago
> 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)?
- nullindividual 3y ago> 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.
- Nextgrid 3y agoIsn'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.