Re: Salsa as authentication provider for Debian
On Fri, Apr 10, 2020 at 12:06:42PM +0200, Bastian Blank wrote:
> On Wed, Apr 08, 2020 at 03:18:58PM +0000, Luca Filipozzi wrote:
> > > - Salsa, how should it work together.
> > Gitlab can use OIDC as an OmniAuth provider.
>
> And here the problems begin.
>
> Sure, just using it as OmniAuth provider works. But this only provides
> authentication.
>
> But, as Sam correctly mentioned, as all others ignored it: we need
> user life cytle. And just using OmniAith does not provide any life
> cycle control.
>
> > > - 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.
>
> You are opting in to maintain three monsters:
> - Java
> - Wildfly
> - Keycloak
Java is already maintained by a team.
I'm not proposing to maintain wildfly independently from keycloak. I
appreciate that there's a 'vendor library' discussion here.
> > > 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.
>
> No, Keycloak is running as OIDC server in this case, so it _provides_
> all the settings via the metadata discovery mechanism.
>
> It's just that the existence of most of those options negates the
> possibility to allow a random user to use it safely.
There are two things that I need to think about here:
(1) how to allow users to add SPs
(2) how hard is it to add SPs
> > > - it can have forms without a required field, which can't be saved at
> > > all.
> > Not sure what you're describing, here.
>
> Just random bugs.
>
> - Enable "email as username"
> - Try to add a user by admin interface
>
> > > - 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.
>
> The latest installation doc is pretty specific:
>
> https://www.keycloak.org/docs/latest/server_installation/#system-requirements
Maybe I'll file a documentation bug seeking a correction.
Redhat have worked hard to keep wildfly operable on the latest GA java
version. In other words, keycloak9 on wildfly18 on java11. I expect that
kecloak10 on wildfly19 will be released soon: wildfly19 was released a
few weeks ago.
Their support for latest GA java will cease, temporarily, with java14
because they are still digesting the impact of package removals compared
to java11.
--
Luca Filipozzi
Reply to: