firstyear

6 ms·

1. 1.▲
   by firstyear 5y ago

   This is exactly what Kanidm does, and there is already some ideas around application password validation via the LDAP facade.
2. 2.▲
   by firstyear 5y ago

   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!
3. 3.▲
   by firstyear 5y ago

   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
4. 4.▲
   by firstyear 5y ago

   This is intended to provide oauth2 and oidc, which means you won't need keycloak.
5. 5.▲
   by 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 L
6. 6.▲
   by firstyear 5y ago

   It's Japanese - Kani == Crab. Crab-Identity-Management :)
7. 7.▲
   by firstyear 5y ago

   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 a
8. 8.▲
   by firstyear 5y ago

   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.