Re: [keycloak-dev] Keycloak distribution changes

From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: keycloak-dev(a)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-sub... 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.

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.

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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev