Thank you for publishing this open source project! One question I have though - there are so many projects in this area popping up (eg. Ory‘s Kratos - https://github.com/ory/kratos) - isn’t there a way to collaborate on these larger projects instead of starting new ones? Or are there specific differences or reasons for rebuilding something like Kandim?
Looks to me like the main difference (besides the language) is that this is planning to offer more in the way of OS and network level auth (SSH/PAM/RADIUS) while kratos focuses on app/website level auth. I'm not sure how hard it'd be to extend kratos with those sort of features.
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.
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.)
Trying to read the docs and look through the code, and it all seems very jumbled, like someone had ADHD and went around implementing a dozen different things that relate to identity and authZ. It would seem like the efforts might be best applied as independent components that combine with other open source solutions, to prevent reinventing the wheel, and create more independent composeable solutions that do one thing well.
Seems like the code just grow organically without a super coherent structure. I'm sure there are folks with ADHD who might be able to get through it though.
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.
Interesting that they are choosing to provide an integrated solution including user management and OAuth IdP ( https://github.com/kanidm/kanidm/pull/485 ) rather than plug into existing open source or even commercial offerings.
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.
> Interesting that they are choosing to provide an integrated solution including user management and OAuth IdP ( https://github.com/kanidm/kanidm/pull/485 ) rather than plug into existing open source or even commercial offerings.
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 :)
> 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.
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 :)
Well, objectively, looking at that page or for example the grouper page (https://incommon.org/software/grouper/) I fail to get /exactly/ where grouper fits in, what it does and doesn’t do, and just generally why I would or wouldn’t choose it in my application.
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.
I would have thought that in SCIM provisioning people would invest more time researching for existing projects.
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.
Grouper look promising but there are performance problems with Grouper when you reach a certain scale.
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 :)
I like these types of projects (auth) and happy to see this is a thriving area. I was a little puzzled by the very first line in their gitbook [0] documentation:
“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?
You would be the one overcomplicating the matter by clumping these distinct concepts together.
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?
Within ABAC schemes, Authorization is a boolean function over (Request, Principle, Environment). If you zero the Principle, you can still represent a large number of unique policies considering just the Request and the Environment.
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.
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.
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.
SSH key/ca management is the only thing I can see that makes this different than say AzureAD. I am glad projects like this exist, even though most people can be best served by ping,aad and the like.
Looks like it squarely competes with FreeIPA. Maybe main differentiator is that FreIPA is in python whereas this is in rust (and so less prone to bugs)?
Is it a widely held concept that Rust is less prone to bugs compared to Python? I've only heard it being compared to C, and only wrt. memory safety bugs.
Rust is statically typed and doesn't have null returns, so it's got advantages for correctness, but the big win with Rust vs. Python would be performance, not security.
There's a lot more checks and balances built into rust as a language, so the foot-gun opportunities are less likely - which makes it rather suitable for reliable systems programming.
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.
Yes, I write a fair bit of Rust. I'm just saying: between Python and Rust, there isn't that much of a security difference (you could nitpick things like deserialization in Python, but really the significant security win of Rust is not having memory corruption flaws, which Python has never really had.)
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?
[0] https://kanidm.github.io/kanidm/intro.html
Edit: For those unfamiliar with the concepts:
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.