Hacker News Reader

Comment by gfody | Hacker News Reader

ssh -k is too enterprise for ̶t̶e̶c̶h̶b̶r̶o̶ ̶s̶t̶a̶r̶t̶u̶p̶s̶ small companies that don't want to setup a kerberos realm

View on HN

The problem is, even for large companies, Kerberos can be quite the pain. It's fine for fixed position desktop computers physically located on site or at a remote site with a hardware VPN tunnel - that was what it was built for.

But that is rarely the case any more. People use their own devices (BYOD) that aren't integrated into AD at all, they're using them outside of the office which means there is no VPN available at boot time to deal with token issuance, and the modern "zero trust" crap that uses weird packet filtering black magic instead of proper tun/tap virtual ethernet devices often doesn't play too nice with archaic authentication tools.

On top of that, implementing support for Kerberos in a Dockerized world is just asking for pain.

If you mention Kerberos to most "security" people these days they will think you're talking about Kubernetes.

really? that’s a shame

kerberos is old and clunky but conceptually it got so much right. I’m so sick of the modern idea that i should wake up and babysit my machine through N different oauth dances to log in to all the services i need on a daily basis. once I authenticate once I should be implicitly authenticated everywhere.

That is one of the things that OIDC sorta almost never really managed to pull off consistently.

And like why not just scrub the `sub` and issue a generic id token (solves idp privacy issues too)… if your service can auth with the claims in the generic token great. if you need more then step up. surely VDCs as a concept have had enough time to mature in the thought space for the industry to be comfortable entertaining this.

You can do this with OpenPubkey, since the user's client can sign challenges that include the scope of the authentication.

Doing this on the web requires being really careful design because you can't trust a javascript client sent to you by the party whose scope you want to control. They could just send you a javascript client that approves a different scope. You still need to do something like the OAuth/OIDC origin-based isolation dance.

One time I actually implemented that on OIDC... by having the OIDC login page do a kerberos login :D

this meant that at most you had a short flash on screen for web apps... which is a bit like OIDC/SAML login on windows domains (but I did it with keycloak back then)

Authentik supports this [1] too, kinda. It seems you can set it up to register you based on a bona fide kerberos auth, and logs you in (maybe? would have to check) with kerberos but seems to keep a parallel synchronized authenticator in its own database for OIDC and "modern" auth. Doesn't seem to embed kerberos-isms as "claims" in OIDC either. Might be awesome if it did? Or terrible, depending on how you look at it.

[1] https://docs.goauthentik.io/docs/users-sources/sources/proto...

MIT Kerberos can authenticate using OIDC created token, but in my case I essentially authenticated to Keycloak with HTTP Negotiate with Kerberos, then based on data from LDAP (that was also used by Kerberos) I generated appropriate OIDC token.

I do security (sorry, "security", I guess?), and literally no one thinks this.

Reply on news.ycombinator.com