<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
After lots of experimentation, I think I've finally settled on a
design. Though this whole effort has taken longer than expected, I
don't think the coding will take that long since I've got
experimental code that does the hard stuff. I just need to
rearrange it and clean it up.<br>
<br>
Here is the design. I appreciate your feedback.<br>
<br>
<u><b>Design Goals</b></u><br>
* Support auth-server running in a WildFly domain.<br>
* Eliminate deployment from /deployments directory to make it a
proper service instead of an ordinary app.<br>
* Eliminate need to explode or crack open auth-server.war. Keep it
intact so it doesn't need to be hacked up.<br>
* Load user-provided overlays for keycloak-server.json, SPI jars,
and theme jars.<br>
* Allow uploading overlays from CLI.<br>
* Allow more than one auth-server in a WildFly instance.<br>
* Compatibility with EAP6, EAP7, WildFly8, and WildFly9.<br>
<br>
<br>
<u><b>Management Model</b></u><br>
The Keycloak subsystem introduces a new resource called,
"auth-server". You can define more than one auth-server if you
like. The simplest form just looks like this:<br>
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"><br>
<auth-server name="my-auth-server-name"/><br>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1"><br>
<br>
On startup, this deploys my-auth-server-name.war with web context
"auth".<br>
<br>
There are two optional attributes under <auth-server>. They
are "enabled" and "web-context". Here is an example:<br>
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"><br>
<auth-server name="auth-server1"/><br>
<auth-server name="auth-server2"><br>
<enabled>true<enabled/><br>
<web-context>auth2</web-context><br>
</auth-server><br>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1"><br>
<br>
In a domain environment, there is an additional resource. You
assign the auth server to one or more server groups:<br>
<subsystem xmlns="urn:jboss:domain:keycloak:1.1"><br>
<auth-server name="my-auth-server-name"><br>
<server-group name="group1"/><br>
<server-group name="group2"/><br>
</auth-server><br>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1"><br>
<br>
<u><b>Loading the Auth Server</b></u><br>
The auth-server.war will be loaded from the Keycloak subsystem
module. This is just a convenient place to put it. We could
actually load it from anywhere. Note that it no longer needs to be
exploded.<br>
<br>
<u><b>Using Overalys</b></u><br>
The Keycloak subsystem can overlay or add to the auth-server.war.
Overlays do not touch the original content of auth-server.war.<br>
<br>
To define an overaly, you just drop your files in the proper
directories on the file system. The layout is:<br>
<br>
/overlays/<auth-server-name>/server-config/<br>
/overlays/<auth-server-name>/account-spi/<br>
/overlays/<auth-server-name>/login-spi/<br>
/overlays/<auth-server-name>/other-spi/<br>
<br>
/server-config optionally contains a single json file that replaces
keycloak-server.json<br>
/account-spi optionally contains a single jar file that replaces
keycloak-account-freemarker.jar.<br>
/login-spi optionally contains a single jar file that replaces
keycloak-login-freemarker.jar<br>
/other-spi optionally contains one or more spi jar files to be added
to WEB-INF/lib. Theme jars also go here.<br>
<br>
<u><b>Location of SPI jars and other user-defined overalys</b></u><br>
For now, I'm planning to have the /overlays directory in the
Keycloak subsystem module. They could, for instance, go in a
/keycloak directory such as <wildfly-home>/keycloak. Any
thoughts on this?<br>
<br>
<u><b>Uploading overlays from CLI</b></u><br>
It is already possible to create overalys via CLI. You upload the
content and assign it to deployments and server-groups. The CLI
commands for this are rather complicated and you really need to know
what you are doing. <br>
<br>
We could make this easier by adding simpler CLI operations to the
Keycloak subsystem. However, I think we should hold off on this
until we find out if the directory-based approach is acceptable to
users. In the mean time, we can just document the CLI commands
needed to upload overlays.<br>
</body>
</html>