[keycloak-dev] User Federation Provider Cache

[Stian Thorgersen]

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.


>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160613/32992723/attachment.html