[HN Gopher] Kanidm: A simple, secure and fast identity managemen...
___________________________________________________________________
Kanidm: A simple, secure and fast identity management platform
Author : haveyaseen
Score : 163 points
Date : 2021-10-16 09:36 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| badrabbit wrote:
| 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.
| hs86 wrote:
| Isn't the name also working in Turkish?
| https://translate.google.com/?sl=tr&tl=en&text=kan%C4%B1tlam...
|
| The kanidim conjugation is basically like "I did [verb]".
| firstyear wrote:
| It's Japanese - Kani == Crab. Crab-Identity-Management :)
| mooreds wrote:
| 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.
|
| 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.
| GekkePrutser wrote:
| > 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 :)
| mooreds wrote:
| > 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.
| firstyear wrote:
| 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 :)
| Huma12_ wrote:
| Yes that's it
| _Anima_ wrote:
| Is it a replacement for freeipa? Key cloak?
| mooreds wrote:
| 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)?
| rzzzt wrote:
| 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.
| tptacek wrote:
| 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.
| yaleman wrote:
| 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.
| tptacek wrote:
| 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.)
| yaleman wrote:
| Yes, it's a replacement for both - still in (a rapidly
| developing) Alpha stage currently.
|
| So far LDAP and PAM/NSS modules are fully operational, and
| OAuth's being tested.
| RedShift1 wrote:
| Under features to avoid it says "Being like
| LDAP/GSSAPI/Kerberos", but aren't you just re-implementing these
| things?
| gravypod wrote:
| 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.
| q3k wrote:
| 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.
| haveyaseen wrote:
| It does speak LDAP as well:
| https://www.youtube.com/watch?v=8IaxnSAggkI&t=1507s
| firstyear wrote:
| This is exactly what Kanidm does, and there is already some
| ideas around application password validation via the LDAP
| facade.
| georgyo wrote:
| 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.
| firstyear wrote:
| 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.
| gibsonf1 wrote:
| Making this a Solid Server or starting as a Solid IDP would be
| pretty valuable: https://solidproject.org/
| yaleman wrote:
| OIDC support's been merged, which would likely help with that?
| gibsonf1 wrote:
| Yes, that + PKCE dPoP and all is well
| unixhero wrote:
| Can this be used together with Keycloak in some fashion?
| mooreds wrote:
| Here is the OAuth/OIDC issue:
| https://github.com/kanidm/kanidm/issues/278
|
| 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.
| firstyear wrote:
| This is intended to provide oauth2 and oidc, which means you
| won't need keycloak.
| mindwok wrote:
| Seems like it's intending to replace key cloak, or at least
| some of it.
| JamesBenson wrote:
| 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?
| [deleted]
| SahAssar wrote:
| 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.
| firstyear wrote:
| 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.
| [deleted]
| throwaway984393 wrote:
| 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.
| 5faulker wrote:
| 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.
| firstyear wrote:
| 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.
| permalac wrote:
| Nobody is mentioning a big open source project like Grouper,
| https://incommon.org/trusted-access/
|
| Can someone tell me why is this project, or 4 softwares, not more
| widely known?
| mooreds wrote:
| Incommon is focused on .edus, as far as I understand it. That
| might be why it isn't as well known as it should be.
|
| I've definitely heard of Shibboleth, it's one of the big
| players in OSS SAML implementations.
| chromatin wrote:
| 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.
|
| That's a long-winded way to say "marketing" :)
| permalac wrote:
| 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.
|
| 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...
| yaleman wrote:
| The front page says "the research and education system for
| IAM" ... that reads like it's not for production use and
| would turn me off immediately.
| nick__m wrote:
| 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 :)
| permalac wrote:
| Could you share the setup you ended up using?
|
| In my institution I have to replace a long lived solution
| that even suports a nis domain, and I feel a bit overwhelmed.
| chromatin wrote:
| 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?
|
| [0] https://kanidm.github.io/kanidm/intro.html
| sigg3 wrote:
| auth is auth. Don't overcomplicate the matter.
| politician wrote:
| Authentication and Authorization are distinct concepts whose
| English terms both start with the same prefix.
| nick__m wrote:
| The set of possible Authorization policies without having
| some form of Authentication is quite limited ;)
| politician wrote:
| 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.
| krono wrote:
| 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?
| b0afc375b5 wrote:
| Authentication - can you login or not?
|
| Authorization - should you be able to see the admin
| dashboard or not?
| yaleman wrote:
| Authentication is part of the "accounts" part. :)
| firstyear wrote:
| 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!
___________________________________________________________________
(page generated 2021-10-16 23:00 UTC)