That is not Single-Sign-On, if you have to sign on several times. LDAP is NOT a replacement for Kerberos.
OAuth and alike might be, but when you work with internal users Kerberos is much much better. Also for web services because GSSAPI/spnego stuff just works.
By removing kerberos from base setup openBSD people have once more moved towards irrelevance outside their own closet setups. Kerberos is the only really working method you can use in corporate setups for large amounts of users and achieving SSO. When it's not in base setup, it's just easier to install any decent Linux distro, and skip openBSD. That as market placement decision was yet another major blunder from openBSD folks, and still they wonder why their donations have dried up the last a few years...
Sorry, I didn't really get that single-sign-on and federated authentication is the same thing.
Couldn't you just install Kerberos from ports/package? Most Linux distribution don't come with Kerberos in their base system. I honestly don't believe that a winning argument for pick OpenBSD over Linux would be: "Kerberos is in the base install".
I would agree that is't a bit odd that login_krb5 seems to have just gone away, delete from CVS, but not moved to the ports three. It might be that so few people actually used it that there's no one to maintain it.
> Sorry, I didn't really get that single-sign-on and federated authentication is the same thing.
I don't think it is. SSO is a good feature, and kerberos provides it -- but I was more curious about the more general case. A solid ldap daemon with easy-to-use ssl/tls covers most of the use-cases I was thinking of.
I don't really care much about "winning arguments" -- I'm just curious about the state of secure, working federated authentication. And the fact that it needs to grip rather deeply into the system, therefore it would be nice to have it in base. Linux generally has PAM in base -- for some that is considered bad, for some it is considered convenient. I'm not really interested in judging one way or the other.
> It might be that so few people actually used it that there's no one to maintain it.
Yeah, that's the feeling I got. And it would be worse to keep something that isn't properly maintained. I guess I'd hoped some openbsd'er would hammer out a robust token/ticket based scheme without many of the flaws of kerberos (ie: hardened implementation, proper/modern cryptography primitives combined in a proper modern way, no premature optimization). That'd probably be hopeless to get to work with windows AD though, so maybe there's only a very small set of people that would care.
I'd certainly like (from a technological standpoint, anyway) something like that, that took lessons from window's kerberos/ldap/dns-story, but made something free and robust (possibly with a patch for GINA for windows) -- that allowed stuff like secure encrypted network filesystems etc.
(Come to think of it, I think the fact that I'm sort of enamoured by the concept of NFSv4 with authentication and encryption delegated to kereberos is one of the reasons why I was so surprised/disappointed. Why have ZFS and NFS without v4 and auth/enc support? So beautiful on paper. I guess that basically leaves sshfs (as OpenAFS also requires(?) kerberos).
I'd really like to see a working distributed single-sign on, single sign-off system that support (optional) caching/offline use coupled with a filesystem that is mutually authenticated (client to server, server to client) also with caching and off-line use. But that is simpler than efforts that have gone before...).
Since when did OpenBSD give a crap about market placement?
It was always about correctness and security. They don't keep big complex unaudited piles of crap around for the sake of corporate or mass market appeal.
Nobody was using kerberosV, nobody was interested in auditing it. There's no place for code like that in OpenBSD base.
