Re: [keycloak-dev] Designing Auth Server startup from subsystem
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