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
