Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kanidm: A simple, secure and fast identity management platform

github.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Kanidm: A simple, secure and fast identity management platform

#21

Post by chromatin »

permalac wrote: post #17

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?

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” :)

Re: Kanidm: A simple, secure and fast identity management platform

#22

Post by politician »

sigg3 wrote: post #20
chromatin wrote: post #18

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

auth is auth. Don't overcomplicate the matter.

Authentication and Authorization are distinct concepts whose English terms both start with the same prefix.

Re: Kanidm: A simple, secure and fast identity management platform

#23

Post by krono »

sigg3 wrote: post #20
chromatin wrote: post #18

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

auth is auth. Don't overcomplicate the matter.

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?

Re: Kanidm: A simple, secure and fast identity management platform

#24

Post by permalac »

chromatin wrote: post #21
permalac wrote: post #17

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?

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…

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...

Re: Kanidm: A simple, secure and fast identity management platform

#26

Post by georgyo »

q3k wrote: post #13
RedShift1 wrote: post #6

Under features to avoid it says "Being like LDAP/GSSAPI/Kerberos", but aren't you just re-implementing these things?

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 o…

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.

Re: Kanidm: A simple, secure and fast identity management platform

#27

Post by gravypod »

RedShift1 wrote: post #6

Under features to avoid it says "Being like LDAP/GSSAPI/Kerberos", but aren't you just re-implementing these things?

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.

Re: Kanidm: A simple, secure and fast identity management platform

#29

Post by rzzzt »

mooreds wrote: post #12
_Anima_ wrote: post #10

Is it a replacement for freeipa? Key cloak?

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.

Re: Kanidm: A simple, secure and fast identity management platform

#30

Post by nick__m »

permalac wrote: post #17

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?

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 :)

Post reply on HN