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

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.

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.

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.