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

[Stian Thorgersen]

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 at redhat.com>
> To: keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>