[keycloak-dev] Designing Auth Server startup from subsystem

Wed Sep 17 09:59:01 EDT 2014

This conversation has become hard to follow.  Can you guys summarize 
what you've agreed to?

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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com