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

[Stian Thorgersen]

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 4:27:51 PM
> Subject: [keycloak-dev] Design of Auth Server startup from subsystem
> 
> 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

What's the purpose of this? Are those config options not loaded from standalone/domain.xml?

> /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

Why replace keycloak-*-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.

It would be awesome to have the ability to upload jars and themes from the KC admin console as well

> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev