3 ms·
Especially bundling these together as equally bad/legacy is weird. LDAP itself can actually be quite easy to understand and work with if you limit yourself to a
by q3k 5y ago
Especially bundling these together as equally bad/legacy is weird. LDAP itself can actually be quite easy to understand and work with if you limit yourself to a useful subset of functionality, ie. a account/group directory. Any Kerberos compatibilty/design inspiration should IMO be avoided though, as it was designed to not use public key crypto, and that translates to a lot of its weirdness.
What I’d like to see is one of these modern offerings actually expose an LDAP facade (bonus points for translating app-specific passwords into binds and for flattening nested group membership) so that it’s easy to bridge existing software which expects LDAP into this newfangled web-centric world. Things like an email MTA/MDA, a PHP app that wants a user directory or even nss_ldap for unified UIDs/GIDs across machines.
- haveyaseen 5y agoIt does speak LDAP as well: https://www.youtube.com/watch?v=8IaxnSAggkI&t=1507s https://www.youtube.com/watch?v=8IaxnSAggkI&t=1507s
- georgyo 5y agoKerberos' use of symmetric keys is actually one of its strengths. In a post-quantum world, kerberos is significant more resistant to attack. Kerberos suffers in other areas, suck as only doing authentication but not authorization, and realm discovery is not trivial. EDIT: Thinking further, I think you are taking about the fact that you need to get a secret key (keytab) from the KDC to do authentication, where as in other auth technologies you are giving the public key to a server and no sensitive information ever has to be transported. That is true.
- firstyear 5y agoThis is exactly what Kanidm does, and there is already some ideas around application password validation via the LDAP facade.