[keycloak-dev] Designing Auth Server startup from subsystem

[Stan Silvert]

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