reminder: I'm answering these linearly and i'm speaking from what I know
(keycloak) not what I don't (LLNG). I expect LLNG is generally similar.
On Tue, Apr 07, 2020 at 08:53:47AM +0200, Bastian Blank wrote:
> On Mon, Apr 06, 2020 at 04:09:38PM +0000, Luca Filipozzi wrote:
> > That said, please consider an approach that would see keycloak used as
> > an idenitity broker, allowing external users to create accounts using
> > social identities that are then promoted to full Debian identities (in
> > LDAP) if they complete the onboarding process.
>
> You are proposing a different idea, however you are not yet proposing a
> project with actionable items on it. If you think this is worthwhile,
> please provide at least the following things:
Responding to "here's an idea: try keycloak" with "publish a full plan"
creates a mountain when we're just at the foothills. I appreciate that,
from your perspective, you've been at this for a year and are
frustrated. I'll respond briefly to these below but, if we want a
fulsome plan, we should create a wiki page with the use cases and
evaluate things against the use cases a bit more.
> - Workflows, esp non-DD to DD and vice versa.
non-DDs can create accounts locally in keycloak and/or tie them to
social identity providers ("let them use existing credentials"). If they
becomee DDs, later, we add them to LDAP and cause them to 'merge' their
accounts on next login (or we use keycloak's API).
> - Self service, e.g. user signup, how do users add OIDC clients, how add
User signup is described above. Individual services could accept all
users or could require specific role assignment. Service owners would
then need to decide on role assignment mechanism.
I've not tried empowering non-admin users to add service providers
to a keycloak IdP. I don't doubt it's possible, just have to try.
> groups/roles to OIDC info.
Yes, keycloak has powerful mapping capability to allow groups/roles to
be exposed as assertions to service providers.
> - Salsa, how should it work together.
Gitlab can use OIDC as an OmniAuth provider.
> - Additional features
> - Who is willing to maintain this long-term
I'm not committing DSA to this but I'm encouraged by their interest in a
demo.
There are at least three people on the thread who are familiary with
SAML/OIDC who are interested in supporting this service.
> - Exit strategy
I'm still at ideation.
> Anyway, I took a quick look into Keycloak.
>
> What I find particular interesting is:
> - they use UUID for user identification
internally, yes. what is passed to a service provider as an identity
assertion can be configured through mapping rules on an SP-by-SP basis
> - users and groups can have arbitrary attributes attached to them,
> however they are not self service
> - it is a complete authorization solution
>
> What isn't so great
> - no particular good admin interface (there are 40+ settings for each
> OIDC client alone)
Nearly all of those settings are auto-populated by exchanging metadata.
In SAML, the SP and the IdP exchange XML documents containing the
metadata. Tedious but works. In OIDC, the SPI and the IdP point to each
other's 'well-known' configuration URLs to pull in the metadata. The
OIDC folks learned from SAML.
> - it can have forms without a required field, which can't be saved at
> all.
Not sure what you're describing, here.
> - jboss. Who considers itself capable of running public jboss
> applications safely and securely?
Yes, there's a general lack of interest in Java and JBoss in our
community.
> Showstopper
> - no self service for group or even OIDC clients
More investigation required, frankly.
> - no U2F (okay, GitLab also still needs to make the step to webauthn)
> - requires Java 8, which is not supported on Debian Buster
This isn't true. I'm running keycloak in a demo for work using
openjdk-11-jre-headless. Their documentation would do well to say Java 8 or
later.
> I was not able to see the killer feature of this setup or at least one
> feature that we must have.
I think the 'killer feature' is independent of Keycloak. It's the
introduction of an identity broker that offers a single place for
service providers to integrate, offers social-to-identity for users,
etc.
--
Luca Filipozzi
