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

On 10/1/2014 4:07 PM, Bill Burke wrote: > Theme support is unaffected? The short answer is yes, no affect except that you can now put a custom theme in a jar and place in /overlays/<auth-server-name>/other-spi. However, concerning themes, the current location for themes will probably not work in a domain environment because it lives in standalone/configuration/themes. I'm not sure about the consequences of that. Are there default themes available inside the auth-server.war? > > 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 >> _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: keycloak-dev(a)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

/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

From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Thursday, 2 October, 2014 2:08:31 PM Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem On 10/2/2014 2:10 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >> To: keycloak-dev(a)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? That was my original intention. The problem is that the management model needs metadata that is more well-defined than what we have in keycloak-server.json. We could translate our own options to DMR but it would be impossible to know all the options available for third-party providers. So we would have to do a meta-meta thing for that. Yuck. So the next thing I tried was to just imbed the keycloak-server.json directly into standalone/domain.xml. That turned out kind of ugly. Better to just let it be its own file and use the same overlay technique we are using for everything else. Cleaner to do everything the same way. Anyway, that's my reasoning. Feel free to poke holes if you disagree. > >> /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? http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.htm... For account or login SPI, it says to delete these jars or disable with a System property if you want to use your own provider. I chose replace. It doesn't actually change the original auth-server.war on disk. It's a virtual replace.

> >> /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 I agree. Down the road we need to look into it. > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Thursday, 2 October, 2014 2:46:01 PM Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem On 10/2/2014 8:18 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Thursday, 2 October, 2014 2:08:31 PM >> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem >> >> >>>> /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? >> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.htm... >> >> For account or login SPI, it says to delete these jars or disable with a >> System property if you want to use your own provider. I chose replace. >> It doesn't actually change the original auth-server.war on disk. It's a >> virtual replace. > Ah, forgot that was how it used to work - that doc is out of date, sorry! > You don't need to replace or use system properties any more, instead you > configure the provider to use in keycloak-server.json: > > { > "account" : { > "provider": "my-account-provider" > } > } > > Basically Keycloak either retrieves a named provider for an SPI (for > example to get the ldap federation) or just picks the default provider > configured for the server (for example account provider). The default > provider is either specified as above, or if there's only one available > it'll pick that one. That's much better. So I just need one directory where you drop all the SPI jars. Maybe I'll call it /plugins. That name covers both SPI jars and theme jars. > > Made me think about another thing. How should we deal with what providers > are included by default, and what users can add later? For instance we > could just put everything in the auth-server.war as we do now, or we could > have a simple mechanism to add those needed (stuff like ldap, google > login, etc, etc..). > Is there a reason to leave them out?