4 ms·

Under features to avoid it says "Being like LDAP/GSSAPI/Kerberos", but aren't you just re-implementing these things?

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 ago
  It 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 ago
  Kerberos' 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 ago
  This is exactly what Kanidm does, and there is already some ideas around application password validation via the LDAP facade.
gravypod 5y ago
I think a good benchmark for most APIs is if someone, who isn't a subject matter expert, can come in and understand the facade the system exposes. For most LDAP/SSO/IdP/etc systems I'm completely and utterly lost without spending hours reading manuals and even then it's iffy. With this project I looked at this graph and instantly knew their head is in the right space: https://kanidm.github.io/kanidm/#why-do-i-want-kanidm https://kanidm.github.io/kanidm/#why-do-i-want-kanidm It seems like they are reinventing the API for what identity management should be and then calling that API from points of enforcement (LDAP, RADIOS, etc). I have a feeling, as long as deploying this is simple, it would be amazing especially if their API exposes a limited amount of data that could be stored. It seems like from this graph that "Account Data References [kanidm]" which is a great sign: this is not a shared database, this isn't a complicated spec, this is a service that manages a mapping of login credentials => (UUID, metadata) in a secure way and integrates into "everything". You can then run whatever things on top of that which you need (email, corporate profile, etc) which, if this API is simple enough, isn't too hard to build or buy especially if the SSO token contains a display name, username, and email since, in my experience, that's all most websites ever use from a jwt since the entire space is too unstandardized on everything else.
firstyear 5y ago
It depends how you look at it - as a professional LDAP developer, I know the ins and outs pretty well, and the issue is that both LDAP and Kerberos "limit" our thoughts on a design. If we come at a problem and say "lets use LDAP, now lets solve the problem" we will be limited by LDAP's ability. But if we say "Here's our problem, how could we solve it?" we can take a completely different approach. So there are many parts inspired by the GOOD bits of LDAP and there are many parts that are completely different.

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 ago
It 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 ago
Kerberos' 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 ago
This is exactly what Kanidm does, and there is already some ideas around application password validation via the LDAP facade.

gravypod 5y ago

I think a good benchmark for most APIs is if someone, who isn't a subject matter expert, can come in and understand the facade the system exposes. For most LDAP/SSO/IdP/etc systems I'm completely and utterly lost without spending hours reading manuals and even then it's iffy. With this project I looked at this graph and instantly knew their head is in the right space: https://kanidm.github.io/kanidm/#why-do-i-want-kanidm https://kanidm.github.io/kanidm/#why-do-i-want-kanidm It seems like they are reinventing the API for what identity management should be and then calling that API from points of enforcement (LDAP, RADIOS, etc). I have a feeling, as long as deploying this is simple, it would be amazing especially if their API exposes a limited amount of data that could be stored. It seems like from this graph that "Account Data References [kanidm]" which is a great sign: this is not a shared database, this isn't a complicated spec, this is a service that manages a mapping of login credentials => (UUID, metadata) in a secure way and integrates into "everything". You can then run whatever things on top of that which you need (email, corporate profile, etc) which, if this API is simple enough, isn't too hard to build or buy especially if the SSO token contains a display name, username, and email since, in my experience, that's all most websites ever use from a jwt since the entire space is too unstandardized on everything else.

firstyear 5y ago

It depends how you look at it - as a professional LDAP developer, I know the ins and outs pretty well, and the issue is that both LDAP and Kerberos "limit" our thoughts on a design. If we come at a problem and say "lets use LDAP, now lets solve the problem" we will be limited by LDAP's ability. But if we say "Here's our problem, how could we solve it?" we can take a completely different approach. So there are many parts inspired by the GOOD bits of LDAP and there are many parts that are completely different.