Re: [keycloak-dev] Keycloak distribution changes

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

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