[keycloak-dev] Offline tokens - step 1

[Bill Burke]

On 9/22/2015 9:46 AM, Marek Posolda wrote:
> Not sure when to save it then? Also I am not sure why offline sessions
> should be more "special" then other UserModel stuff like
> IdentityProvider/Social links, consents or even role mappings?
>
>
> I personally think that we need more flexibility in chaining of
> UserProvider implementations. That way, the UserFederationProvider will
> delegate to "next" provider in the chain . And the next storage can be
> either:
>
> - persistent - in this case you have chaining like: federation -> JPA
>
> - inMemory - in this case you have chaining like: federation -> inMemory
> -> JPA
>

I like the chaining idea.  It should be explored.

> The inMemory storage will have flexibility to specify which stuff
> exactly is saved in memory and which stuff should be delegated to "next"
> storage (JPA). In that way, people can specify that for example whole
> UserModel can be saved in memory despite offlineSessions and consents.
> Those are only things, which will be delegated to last "persistent"
> storage in the bottom of the chain.
>
>
> We should also have possibility to put CacheUserProvider on the top of
> the chain - currently the top provider is always hardcoded to
> UserFederationManager.

UserFederationManager is useful because it can handle common logic.

> This is not very performant for the
> UserFederationProviders with "constant" data. For example if you have
> LDAP when data wasn't changed at all during last year, you don't need to
> always call LDAPFederationProvider.validate and constantly ask LDAP if
> user still exists there. So instead you will put cache provider on top
> and UserFederationManager under it.
>

That's not how it works.  Cache is always queried first, isn't it?

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