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

[Bill Burke]

I am off on Monday.  Damn kids have a holiday and I'll be driving them 
around to their activities from 7:00am-7pm.

On 1/16/2015 10:32 AM, Stian Thorgersen wrote:
> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com