Re: [keycloak-dev] Location of User Federation Provider jar in Keycloak 1.1 Beta-2

Sent out an invite for a meeting on Monday (4pm CET), is everyone available to join? I'd like to discuss this issue in person before doing the release. ----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Friday, 16 January, 2015 4:28:37 PM > Subject: Re: [keycloak-dev] Location of User Federation Provider jar in Keycloak 1.1 Beta-2 > > On 1/16/2015 9:42 AM, Bill Burke wrote: >> >> On 1/16/2015 9:20 AM, Stan Silvert wrote: >>> On 1/16/2015 9:07 AM, Stian Thorgersen wrote: >>>> Currently, I'm not overly happy with releasing 1.1.0.Final and it's down >>>> to this issue. I should have raised it before, but it completely slipped >>>> my mind :( >>> We did talk about this at great length before. I tried and tried to >>> preserve the "drop it in the file system" approach. It just plain won't >>> work for domains. >>>> IMO we need: >>>> >>>> 1. A usable way to deploy a provider without using the CLI GUI >>>> 2. Ideally be able to deploy a provider with an offline server >>> We have 5 ways to add a provider: >>> 1. CLI >>> 2. CLI GUI >>> 3. CLI script >>> 4. Explode the WAR in the subsystem and drop it in WEB-INF/lib >>> 5. Use the war dist and do it the old way. >>> >> 6. Create a module for your new provider. Import that module (with >> service import too) into the main Keycloak module. Of course this >> requires knowledge of JBoss Modules. Not sure if this would work. You >> tell me. > I tried that and ran into problems. I consulted with Jason and Stuart > to see if there was any way to get it to work. They concluded that it > probably could be made to work but it would require moving everything > out of the WEB-INF/lib and creating modules for each jar. I don't > remember all the details but I can probably find the chat log where we > discussed it. > > At the time I didn't want to go that far because pulling everything out > of the WAR and forcing the user to create modules seemed like too > radical of a change. But maybe we need to revisit that. We've already > been talking about moving more stuff into modules. If we decide to not > support the auth server on other platforms then it would make even more > sense to go ahead and do it because we wouldn't be tied to testing > everything as a WAR. >> >> BTW, come to think of it, this upload through CLI just won't work, if >> the provider has even one third-party library dependency. > It still works. You can upload as many provider jars as you want. >> >> Stan, can you explain again the issue with domain mode? Is it that >> you're trying to secure the domain controller itself with keycloak? >> >> > The domain controller won't be secured with Keycloak until we integrate > with Elytron. But having Keycloak compatible with domain mode is a > piece of that puzzle. > > Deployment scanners are not allowed in domain mode. You upload to the > domain controller and the deployment is distributed to wherever you want > it to run. So there is no place in the file system where you can just > copy a file and have it become part of the deployment. And as I found > out, there is no way to create your own deployment scanner that will > work. The architecture blocks you from doing that. > > Operationally, using overlays is a lot cleaner for upgrades, especially > in domain mode. Your provider jar is the thing most likely to change. > So when it does, you just need to upload the one jar and you are done. > Same is true for keycloak-server.json changes. > > If you used a single hacked-up WAR, you would need to rebuild the entire > WAR off line and upload the whole thing. So you would also need to keep > up with manually versioning your own customized WAR. > _______________________________________________ > 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