[keycloak-dev] Designing Auth Server startup from subsystem

[Stan Silvert]

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