[keycloak-dev] Keycloak distribution changes

Tue Apr 14 08:13:20 EDT 2015

----- 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.

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.

> 
> 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
> 