That's nice. (I too think it's simpler to get everything okay well tested, when it's all in one place, rather than different software, possibly from different vendors, that's supposed to integrate with each other to accomplish the same thing.)
Also nice that it's written in Rust. And that you've chosen the MPL 2.0 license.
And that Kanidm is an OIDC Identity Provider, I've been looking for that :- ) And WebAuthn
(Keycloak is nice, however it's Java and thus a bit resource intensive (RAM), and some other things.)
Here's a design doc about their OAuth choices: https://github.com/kanidm/kanidm/blob/master/designs/oauth.r...
It would seem simpler to go with the Ory approach of "best in breed" for, say network management tooling (most of which they already have implemented), and then integrate with Keycloak, Okta, FusionAuth, the Ory suite, etc for user management. Maybe they didn't want to do that because there are synergies with integrated user management? I dunno, seems like there are a lot of user management tools out there.
I also find it interesting that they explicitly disallow a goal of building a better LDAP server. I think there's a lot of room to run in that. My employer has had users show a fair bit of interest in a modern experience with LDAP layered on top ( https://github.com/FusionAuth/fusionauth-issues/issues/954 ) and I talked to someone at a conference that had built a whole business out of virtual LDAP: https://www.radiantlogic.com . They were working with companies with multiple LDAP based auth systems, and providing a way to have apps see one view of the user.
Maybe kanidm isn't that project, but it seems like a modern OSS LDAP implementation would be welcomed by the software community.
Disclosure: I work at FusionAuth.
I can understand their focus of being completely open and self-contained. At work we use Azure AD and I've been looking at an IDP to use personally. I actually do have access to a personal AAD instance. But I don't want to give commercial parties access or data about my stuff.
Existing open source offerings would be ok but then you have a codebase to consider that you don't manage and it could make the product heavier. The only thing I'd 'outsource' would be algorithm stuff in libraries like crypto.
I'm looking for something lightweight that is stand-alone and this looks really interesting. I'll definitely try it out.
Just wanted to point out that there is definitely a niche for it :)
Thanks for the info! I get that controlling the whole stack can make sense (great post about this here: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-... ) but just seems like yet another user management system might not be the best use of resources. But I'm not entirely in that world (of deploying ssh keys to servers, for example) so appreciate the perspective.
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 :)
The kanıdım conjugation is basically like "I did [verb]".
Can someone tell me why is this project, or 4 softwares, not more widely known?
Likely, busy people don’t spend a lot of time digging in to software that doesn’t effectively communicate clearly what it is, unless they know from a trusted colleague, friend, or other resource that the software/tool will be essential or a major win for them.
That’s a long-winded way to say “marketing” :)
Said that, I fully understand why people would not invest enough time to understand the Grouper environment, I going through it and feels like a punishment.
If someone wants to see the potential, check this list of known users and their use cases : https://spaces.at.internet2.edu/display/Grouper/Community+Co...
When I tried to import my institution LDAP, I had to exclude the major groups it was meant to manage as they were basically undeletable. Sure you could easily delete one reference group ex (u:ref:students:adm:adm101:20201:01) but deleting all the group from a faculty (evrything under u:ref:students:adm) took more than a weekend (I killed the job and recreated the database from a snapshot).
In the grouper mailing list it was suggested to keep only the previous, current and next trimester but this arrangement was unworkable at my institution, there are valid usecases that require groups from the 5 last years.
Things might have changed since I did this experiment a few years ago and I dont do identity management anymore :)
In my institution I have to replace a long lived solution that even suports a nis domain, and I feel a bit overwhelmed.
I've definitely heard of Shibboleth, it's one of the big players in OSS SAML implementations.
“Kanidm is an identity management server, acting as an authority on accounts and authorisation within a technical environment.”
Shouldn’t that be authentication, or am I misunderstanding the purpose of Kanidm?
Edit: For those unfamiliar with the concepts:
Authentication: subject identity - is the user who they claim to be?
Authorization: subject permissions - is this user permitted to execute that action?
Authorization - should you be able to see the admin dashboard or not?
They are talking here: https://github.com/kanidm/kanidm/pull/485 about being an IdP with support for OIDC, so once that is implemented you could probably federate to Keycloak (or any other compliant IdP).
Might be worth filing an issue, I'm sure they'd love the feedback.
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.
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.
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.
So far LDAP and PAM/NSS modules are fully operational, and OAuth's being tested.
And getting back to this particular case... kanidm is fast AND reliable. There's a lot of testing going on comparing it to 389 DS.