[keycloak-dev] Keycloak distribution changes

Tue Apr 14 08:32:58 EDT 2015

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 April, 2015 2:27:03 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> On 4/14/2015 8:13 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 14 April, 2015 2:03:39 PM
> >> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>
> >> Marko and I discussed this yesterday in HipChat/MW Security.  After
> >> giving it a lot of thought, I came to most of the same conclusions as
> >> Stian.
> >>
> >> I do think that having a single subsystem with three different flavors
> >> (client, server, and both), is a legitimate choice.  It's really easy to
> >> do as you just have to put conditionals on the calls to
> >> registerSubmodel() in KeycloakExtension:
> >> https://github.com/keycloak/keycloak/blob/master/integration/keycloak-subsystem/src/main/java/org/keycloak/subsystem/extension/KeycloakExtension.java#L81-L84
> >>
> >> Then you get a single subsystem that can be installed in three different
> >> ways.  It's up to the installer to add the modules needed for a
> >> particular flavor.
> > Sure, but I can't see any long term benefits with that approach
> >
> >> The feature that needs both server and client in the same subsystem is
> >> "seamless hello world".  The idea is that you set up the subsystem so
> >> that any WAR deployed to the server automatically gets Keycloak SSO.
> >> This requires programmatic setup of both client side and server side.
> >> That's easier to do if everything is in one place.
> > If you're requiring programmatic setup directly to Keycloak you're doing it
> > wrong IMO. Problem is then it won't work with a remote Keycloak server. It
> > should be seamless if you're using a local or a remote server.
> No, I'm not thinking of doing direct setup.
> 
> I haven't coded the part that does the server side.  I only have code
> that auto-configs the client side.  My intention was to be able to say,
> "Use the local server by default".  For that you need to be able to find
> if there is a single local server.  You can then automatically determine
> its web context.  It's still doable if they are split though.  Just a
> little harder.  Or, that determination can be done manually.
> >
> > Instead the adapter sub-system should use the admin rest api to configure a
> > local or remote Keycloak server. In the future we'll add dynamic client
> > registration which should make this even easier.
> Sounds great.  We'd probably want to do that before we go any further
> with seamless hello world.

Or, use the admin api (there's a java client to make it easier) so we can experiment with it and find out exactly what's needed?

> >
> >> But honestly, I'm leaning toward Stian's arguments at the moment.
> >>
> >> On 4/14/2015 7:32 AM, Stian Thorgersen wrote:
> >>> I don't see how splitting the sub-system will make it more difficult for
> >>> Elytron or OOTB config for examples. Anything we add to those should be
> >>> just as usable whether or not Keycloak is running locally or remotely.
> >>>
> >>> Splitting the sub-system has the advantages of isolating two very
> >>> different
> >>> features. Deploying and configuring Keycloak itself should be completely
> >>> separated from configuring applications that use Keycloak. It makes the
> >>> distribution of either cleaner. Also, for the server sub-system we only
> >>> need to support latest WildFly and the distribution we build on-top of
> >>> WildFly core/servlets-only. While for the adapter sub-system we'll need
> >>> to
> >>> support a range of EAP versions as well as potentially multiple WildFly
> >>> versions.
> >>>
> >>> Other than some initial boiler plating I don't see any benefits of having
> >>> a
> >>> single sub-system, and it'll be much easier to maintain two separate
> >>> sub-systems IMO as they do two completely different things and it should
> >>> be possible to deploy a single one of the sub-system or both together.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Marko Strukelj" <mstrukel at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, 14 April, 2015 12:29:30 PM
> >>>> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>>>
> >>>> Yesterday a had a little conversation with Stan, and he thought the code
> >>>> split may result in a lot of subsystem plumbing code duplication and
> >>>> make
> >>>> things more difficult for Elytron integration, and make OOTB config for
> >>>> examples slightly more complicated ...
> >>>>
> >>>> As far as I understood it the idea is a code split, and module
> >>>> dependencies
> >>>> split, and it's there to be able to make a standalone distribution that
> >>>> will
> >>>> not contain any of adapter-specific configuration / dependencies /
> >>>> modules.
> >>>> The price of duplicated plumbing, and a lack of OOTB adapter
> >>>> configuration
> >>>> for standalone  - server and adapter in the same WildFly - is agreed to
> >>>> be
> >>>> outweighed (so I understand) by some benefits - but I'm not sure what
> >>>> those
> >>>> are (cleaner codebase? The ability to be able to install adapter only
> >>>> into
> >>>> existing WildFly without also installing the server parts -
> >>>> auth-server.war?
> >>>> Something else?)
> >>>>
> >>>> Server / adapter split will have to identify code that is shared between
> >>>> server and adapter, which will be modularized out of the subsystem.
> >>>>
> >>>> Stan can tell more, but as I understood his idea was that the one and
> >>>> single
> >>>> subsystem could present two faces, and based on availability of some
> >>>> modules
> >>>> for example present a server only, an adapter only, or a full view of
> >>>> configuration options, and that might be simpler than splitting existing
> >>>> subsystem into three parts - server, adapter, shared.
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> We've discussed this and I hope we're all on the same page, but just to
> >>>>> confirm here's what we've discussed:
> >>>>>
> >>>>> Keycloak Server
> >>>>> ---------------
> >>>>>
> >>>>> * Standalone
> >>>>>     - Built on WildFly servlet-only
> >>>>>     - No 'standalone/deployments' directory
> >>>>>     - Includes server only sub-system
> >>>>>     - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples,
> >>>>>     etc,
> >>>>>     included)
> >>>>>     - Keycloak deployed to root context (http://localhost:8080)
> >>>>> * Demo Bundle
> >>>>>     - Built on WildFly full
> >>>>>     - Includes demo ready deployed and configured
> >>>>>     - Includes server and adapter sub-systems
> >>>>>     - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes
> >>>>>     docs,
> >>>>>     examples, etc.)
> >>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
> >>>>> * Installer
> >>>>>     - Installs Keycloak server sub-system into existing WildFly
> >>>>>     - Only "latests" WildFly at the time of release is supported
> >>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
> >>>>>
> >>>>>
> >>>>> Keycloak Embedded
> >>>>> ------------------
> >>>>>
> >>>>> * Consumed by external JBoss projects to embed Keycloak
> >>>>> * Build-your-own WAR example repo
> >>>>>
> >>>>>
> >>>>> Keycloak Adapters
> >>>>> -----------------
> >>>>>
> >>>>> * Separate download from server
> >>>>> * Installer for WildFly subsystem adapter
> >>>>> * We still have to decide if adapters should have a separate release
> >>>>> cycle/version to the server
> >>>>> * We still have to decide if Java adapters should be moved to separate
> >>>>> github
> >>>>> repo
> >>>>>
> >>>>>
> >>>>> Finally, a set of releated tasks
> >>>>> --------------------------------
> >>>>>
> >>>>> * Split subsystem into server and adapter
> >>>>> * Use standalone.xml instead keycloak-server.json (json will still be
> >>>>> supported for embedded)
> >>>>> * Add support to use dmr/jboss-cli for configuring the server (for
> >>>>> example
> >>>>> a
> >>>>> single jboss-cli batch script can add data-source and set Keycloak to
> >>>>> use
> >>>>> it)
> >>>>> * Add support to use dmr/jboss-cli for configure realms, apps and users
> >>>>> * Add support to use root-context with server subsystem
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 