[keycloak-dev] Designing Auth Server startup from subsystem

Stan Silvert ssilvert at redhat.com
Tue Sep 16 16:03:37 EDT 2014


I have a prototype working and I think I've got the lay of the land.  
Now I need help to make design decisions.  (BTW, every time I say 
WildFly I mean WildFly or EAP)

*Background*
Deployment to the /deployments directory is generally discouraged, 
especially in production environments.  In a domain configuration, it is 
impossible because there is no deployment scanner and no /deployments 
directory.  Today, if you want to use the Keycloak Auth Server in a 
domain, you must upload the WAR to the content repository and assign it 
to one or more server groups.

This not only adds extra installation steps, it complicates management 
of the auth server.  The auth server could be assigned to WildFly 
instances where Keycloak modules are not installed. Furthermore, WildFly 
administrators with highly restricted roles in the web console and CLI 
would have too much control over the auth server deployment.  IMO, only 
Administrator or higher should be able to control the auth server 
deployment. [1]

*Subsystem-based Deployment*
The Keycloak Auth Server can instead be deployed as part of the Keycloak 
Subsystem[2].  The plan is to make subsystem deployment an option on 
both standalone and domain installations.  This makes the Auth Server 
into more of a service instead of an end-user application.

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

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?

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?

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.

What are the plans and considerations for clustered auth server? 
Anything I should be aware of at this point?

[1] 
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_tip_120
[2] See "A Mixed Apporach" https://developer.jboss.org/wiki/ExtendingAS7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140916/f7ce3f43/attachment-0001.html 


More information about the keycloak-dev mailing list