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

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >