Re: [keycloak-dev] Offline tokens - step 1

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

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.

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.