[keycloak-dev] Keycloak distribution changes

Tue Apr 14 08:27:03 EDT 2015

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