[keycloak-dev] Design of Auth Server startup from subsystem

[Bill Burke]

Theme support is unaffected?

On 10/1/2014 10:27 AM, Stan Silvert wrote:
> 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.
>
> Here is the design.  I appreciate your feedback.
>
> _*Design Goals*_
> * Support auth-server running in a WildFly domain.
> * Eliminate deployment from /deployments directory to make it a proper
> service instead of an ordinary app.
> * Eliminate need to explode or crack open auth-server.war.  Keep it
> intact so it doesn't need to be hacked up.
> * Load user-provided overlays for keycloak-server.json, SPI jars, and
> theme jars.
> * Allow uploading overlays from CLI.
> * Allow more than one auth-server in a WildFly instance.
> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
>
>
> _*Management Model*_
> 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:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>              <auth-server name="my-auth-server-name"/>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>
> On startup, this deploys my-auth-server-name.war with web context "auth".
>
> There are two optional attributes under <auth-server>.  They are
> "enabled" and "web-context".  Here is an example:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>              <auth-server name="auth-server1"/>
>              <auth-server name="auth-server2">
>                       <enabled>true<enabled/>
>                       <web-context>auth2</web-context>
>              </auth-server>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>
> In a domain environment, there is an additional resource.  You assign
> the auth server to one or more server groups:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>              <auth-server name="my-auth-server-name">
>                       <server-group name="group1"/>
>                       <server-group name="group2"/>
>              </auth-server>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>
> _*Loading the Auth Server*_
> 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.
>
> _*Using Overalys*_
> The Keycloak subsystem can overlay or add to the auth-server.war.
> Overlays do not touch the original content of auth-server.war.
>
> To define an overaly, you just drop your files in the proper directories
> on the file system.  The layout is:
>
> /overlays/<auth-server-name>/server-config/
> /overlays/<auth-server-name>/account-spi/
> /overlays/<auth-server-name>/login-spi/
> /overlays/<auth-server-name>/other-spi/
>
> /server-config optionally contains a single json file that replaces
> keycloak-server.json
> /account-spi optionally contains a single jar file that replaces
> keycloak-account-freemarker.jar.
> /login-spi optionally contains a single jar file that replaces
> keycloak-login-freemarker.jar
> /other-spi optionally contains one or more spi jar files to be added to
> WEB-INF/lib.  Theme jars also go here.
>
> _*Location of SPI jars and other user-defined overalys*_
> 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?
>
> _*Uploading overlays from CLI*_
> 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.
>
> 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.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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