[keycloak-dev] Designing Auth Server startup from subsystem

[Bill Burke]

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.

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


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


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

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


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