[keycloak-dev] Designing Auth Server startup from subsystem

Wed Sep 17 13:15:20 EDT 2014

On 9/17/2014 9:59 AM, Bill Burke wrote:
> This conversation has become hard to follow.  Can you guys summarize
> what you've agreed to?
I think I got my questions answered.  We veered into a discussion about 
how to deal with plugins.

The auth server will live in its own module and be deployed by the 
Keycloak subsystem.

Here are the options for dealing with plugins that use the 
META-INF/services pattern:
1)  Leave the WAR as exploded.  So it's the same as today except you 
drop your jar in the WAR in the module instead of the WAR in the 
/deployments directory.
2)  Put the jar in its own module and reference it from the Keycloak 
subsystem
3)  Put the jar in the same module as the auth server and add a line in 
module.xml for it.
4)  Use a tool to accomplish one of the first three.

I think that #1 and #3 will require no additional code.  So for the sake 
of getting this out sooner, we might want to pick one of those for the 
time being.

>
> On 9/17/2014 9:19 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 17 September, 2014 3:15:18 PM
>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>
>>> On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>>
>>>>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>>>>
>>>>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>>>>> *Questions and Design Decisions*
>>>>>>>>> The Auth Server WAR will live in its own module.  Is there any reason
>>>>>>>>> for it to be in exploded form?
>>>>>>>>>
>>>>>>>> We have exploded form so that user can plug in their own custom user
>>>>>>>> federation providers and other plugin SPIs.  These providers are
>>>>>>>> scanned
>>>>>>>> for in the classpath using the META-INF/services pattern.
>>>>>>> They could (should?) install the plugin as a module and expose the
>>>>>>> services from there.  But for now I'll use exploded form.
>>>>>> I don't personally like the current way we add plugins to the
>>>>>> auth-server.war. Would it be possible to "deploy" plugins in
>>>>>> "deployments"? Alternatively have plugins added as modules, then either
>>>>>> have the Keycloak subsystem automatically detect them on startup or
>>>>>> require users to register them with Keycloak somehow.
>>>>> Anything is possible, but adding as a deployment is definitely not the
>>>>> way to go.  Deployments are for end-user applications.
>>>> Plugins are end-user things though, and it certainly would make it easier
>>>> to develop plugins if you could do "mvn wildfly:deploy" ;)
>>> I agree.  That's why the EAP team is working on tooling for that sort of
>>> thing.  Before WildFly/AS7, everything was a deployment. But we've
>>> changed that now to divide the world into applications and services.
>>>>> Adding as a module is the cleanest way to do this but it requires a
>>>>> little more than just copying the jar to the file system.  So we're
>>>>> talking about either creating a module.xml by hand or using a tool.
>>>>>
>>>>> Since there will soon be a keycloak-auth-server module, you could put
>>>>> the jar in that module and add an entry in that module.xml. That's
>>>>> probably a good compromise.
>>>> Whatever we do we should make it simple - we've already had complaints
>>>> about having to copy a jar into
>>>> standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
>>>> updating keycloak-auth-server module.xml is even more work. Also what
>>>> happens when you upgrade the keycloak-auth-server module, wouldn't it
>>>> loose the dependencies added by users?
>>> If you upgrade by hand, it definitely won't lose anything.  How well it
>>> all works in the end will depend on how good the new provisioning tools
>>> are.  We can fill in the gaps with our own tools though.
>>>
>>> If the requirement is to be able to upload the jar, we can accomplish
>>> that one way or the other.
>> Ignoring the underlying details, it would be cool if we had a Maven plugin that could "deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed to make sure it's available.
>>
>>>>>>>>> The Keycloak Subsystem will get a new resource called "auth-server".
>>>>>>>>> Right now I only plan to have one attribute called "enabled".  By
>>>>>>>>> default, this will be false in a domain environment. You don't want an
>>>>>>>>> auth server to boot everywhere you install the keycloak subsystem.  Do
>>>>>>>>> we want this to be true for standalone?  In other words, should the
>>>>>>>>> auth
>>>>>>>>> server automatically boot if the keycloak subsystem is installed on
>>>>>>>>> standalone?
>>>>>>>>>
>>>>>>>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
>>>>>>> You don't want the auth server to boot if you are just using the
>>>>>>> subsystem for clients.  But now that I think about it, I've answered my
>>>>>>> own question.  Whether or not the auth server is enabled is something
>>>>>>> that can be defined when you add the Keycloak feature pack.  So you
>>>>>>> could set the default to whatever you want depending on the situation.
>>>>>>>
>>>>>>> I'm not sure I understand your question about distribution.  With the
>>>>>>> feature pack, Keycloak can be added when a server is first assembled or
>>>>>>> Keycloak can be added on later.  The feature pack lives in the Maven
>>>>>>> repo.  For example, the WildFly full build will use the Keycloak FP to
>>>>>>> add Keycloak and make it part of its download.  The WildFly web build
>>>>>>> probably won't include Keycloak, but you can use the feature pack to add
>>>>>>> it later.
>>>>>>>
>>>>>>> Feature Pack = module references + configuration XML + extra content
>>>>>>>>> Are there any other attributes to add?  The Keycloak subsystem can do
>>>>>>>>> anything it wants to the auth server at deployment time.  It can
>>>>>>>>> change
>>>>>>>>> context params, add modules, boot in some kind of admin-only mode, or
>>>>>>>>> anything else.  Configuration settings on the WAR could be made from
>>>>>>>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
>>>>>>>>> subsystem to do?
>>>>>>>>>
>>>>>>>> there is a keycloak-server.json file.  Maybe that should be
>>>>>>>> configurable
>>>>>>>> in the subsystem too.
>>>>>>> OK.  I'll take a look at that.  Should be very similar to what we do for
>>>>>>> clients configured by the subsystem.
>>>>>> Would it not be best to drop 'keycloak-server.json' and configure it all
>>>>>> from standalone/domain.xml?
>>>>> For WildFly/EAP deployments, I think this will become the preferred way
>>>>> of doing it.   We'll still need keycloak-server.json for other containers.
>>>>>>>>> Do I need to allow for multiple auth server deployments in the same
>>>>>>>>> WildFly instance?  This is quite easy to do.  For the second instance,
>>>>>>>>> it would override the module name of the auth server WAR.
>>>>>>>>>
>>>>>>>> I'm sure there is some weird user that will want to do this.  But I
>>>>>>>> don't think this will be the norm, do you?
>>>>>>> No, not the norm.  Would there be a scenario where someone wanted to
>>>>>>> have prod and test instances of the auth server inside the same WildFly
>>>>>>> instance?  Or maybe someone wants a single WildFly instance to host two
>>>>>>> auth servers from unrelated entities?
>>>>>>>>> What are the plans and considerations for clustered auth server?
>>>>>>>>> Anything I should be aware of at this point?
>>>>>>>>>
>>>>>>>> Might need infinispan configured for clustering going forward.
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>