[feedback] Kanidm comparison table line items

[lastlogin-io]

[feedback] Kanidm comparison table line items

[anderspitman]

Thanks for the explanation!

I've integrated your details into the comparison table.

[anderspitman]

Thanks @Firstyear! One clarification. Upstream OIDC in the table specifically refers to the ability to authenticate with other OIDC IdPs, so for example instead of logging in to Kanidm directly, could I do an OIDC flow with Google instead?

[anderspitman]

I would appreciate hearing your thoughts on forward auth. What are the main security issues that concerned you? It's unfortunate because forward auth provides an excellent UX. Would be great if there was a way to make it more secure so we can have our cake and eat it too.

Also, how do you implemented trusted header auth without doing either forward auth or a full reverse proxy?

[Firstyear]

Thanks @Firstyear! One clarification. Upstream OIDC in the table specifically refers to the ability to authenticate with other OIDC IdPs, so for example instead of logging in to Kanidm directly, could I do an OIDC flow with Google instead?

That's a planned feature, but not implemented today.

I would appreciate hearing your thoughts on forward auth. What are the main security issues that concerned you? It's unfortunate because forward auth provides an excellent UX. Would be great if there was a way to make it more secure so we can have our cake and eat it too.

Generally we've seen a lot of (quality) issues with traefik in production. But the big issue here is that for it to work you have cookies that are being taken from one domain (the idp) and then injected back to the application domain. So improper handling of these means that you have a larger blast radius in case of cookie theft. Where as something like oidc/oauth2 has a clear isolation boundary between the two parts (idp/application). In addition it also relies on correct handling of the header contents which can also be problematic. Finally it confuses things like webauthn which has strict rules about origin and rpID values, so you would end up with needing broader rules for these.

Also, how do you implemented trusted header auth without doing either forward auth or a full reverse proxy?

Ahh I misunderstood what the line item here represented. So we don't do that.