<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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)<br>
<br>
<b>Background</b><br>
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.<br>
<br>
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]<br>
<br>
<b>Subsystem-based Deployment</b><br>
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.<br>
<br>
<b>Questions and Design Decisions</b><br>
The Auth Server WAR will live in its own module. Is there any
reason for it to be in exploded form?<br>
<br>
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?<br>
<br>
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?<br>
<br>
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.<br>
<br>
What are the plans and considerations for clustered auth server?
Anything I should be aware of at this point?<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_tip_120">http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_tip_120</a><br>
[2] See "A Mixed Apporach"
<a class="moz-txt-link-freetext" href="https://developer.jboss.org/wiki/ExtendingAS7">https://developer.jboss.org/wiki/ExtendingAS7</a><br>
</body>
</html>