firstyear

This is exactly what Kanidm does, and there is already some ideas around application password validation via the LDAP facade.

Just for you, I fixed up this line in the book to make it clearer. Issue reports about things like this is docs and clarity are always welcome!

Disclosure: I work on 389-ds at SUSE, so I have a lot to say about LDAP, and why I don't want to re-implement a new LDAP server.

As mentioned, the main goal is "all in one" to avoid the FreeIPA style fragility from using lots of moving pieces. Making everything tight knit gives us a lot of ability to change and adapt to what we need, rather than being bound by what other projects want to do :)

This is intended to provide oauth2 and oidc, which means you won't need keycloak.

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.

It's Japanese - Kani == Crab. Crab-Identity-Management :)

The main reason to do Kanidm is that it's "all in one". I've had a lot of experience with FreeIPA and have learnt that the microservice design is hard to test and hard to make reliable at scale. So a key goal was to be able to create a single bundle, that we can test end to end to ensure reliability.

There actually is a plan and set of designs that worked towards these parts. There was a lot of foundational work, and currently the goal is the integrations on top.