[keycloak-dev] User Federation Provider Cache

[Stian Thorgersen]

On 13 June 2016 at 16:00, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 6/13/16 9:13 AM, Stian Thorgersen wrote:
>
>
>
> On 13 June 2016 at 15:06, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 6/13/16 4:19 AM, Stian Thorgersen wrote:
>>
>> I've never been a fan of how creating user feds outside of the session
>> was done. It's a completely broken concept and has several flaws:
>>
>> a) KeycloakSession doesn't manage instances - we have issues with both
>> multiple instances being created as well as instances not being closed.
>> b) The code that requires an instance needs to know how to create one
>> c) No way to create a custom way to configure/setup - the model approach
>> may work for some, but what if a custom provider wants to store config
>> differently
>>
>> With that in mind this needs to be fix and not monkey patched.
>>
>> When requesting an instance of a user federation it should be:
>>
>> session.getProvider(UserFederationProvider.class, String instanceId)
>>
>>
>>
>>
>> That's it. It would then be up to the factory of figuring out how to
>> instantiate it, not the calling code.
>>
>> A user fed provider is often a generic thing that can be configured
>> multiple times for multiple different stores (i.e. LDAP).  So, the model is
>> a must.  We don't want people configuring fed providers within
>> keycloak-server.json
>>
>> Model will be used by most (all) providers so it needs to be a parameter
>> for creation.  This generic getProvider() method on KeycloakSession just
>> doesn't fit for most situations.  Most mappers fall into this category
>> too.  I have thought about defining a generic ConfigurationModel and
>> datastore that would be used by everything (mappers, fed providers, etc.)
>>
>
> Yes, I know. Please read the thread me and Marek and when we discussed
> this. This really has to be sorted out otherwise we'll continue to have
> issues with it.
>
>
> I read it.  Summary is that you need to be able to associate one instance
> per session and the ability for it to be closed when session ends.  As long
> as we don't think some implementation will want an instance per method call
> on the provider, then all this can probably be done automatically.
>

Another thing to add is that the construction of the instances should be up
to the factory, not the caller. This allows the factory to retrieve the
config (model) from the realm for that particular instance. Alternatively a
factory can also pull the config from elsewhere if it wants to. It should
not be required by calling code to know how to construct the instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/10e09e89/attachment.html