[keycloak-dev] Offline tokens - step 1

[Marek Posolda]

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.

Marek


On 22/09/15 14:45, Bill Burke wrote:
> I've wanted to switch to a URI for userId:  {id}@{provider} or 
> {provider}:{id}.  {id} would be something unique and that makes sense 
> for the fed provider.  Old user ids would just assume that they are in 
> local storage.
>
> I still think this should be a separate datastore from users.
>
> On 9/22/2015 2:44 AM, Marek Posolda wrote:
>> Ok, I can add the methods to UserProvider instead of UserModel and add
>> the UserModel as argument to CRUD methods. So it will use same pattern
>> like we have for FederatedIdentityModel .
>>
>> Still, I would like to use references to token storage by User ID, not
>> by username. I wonder that when we later use in-memory UserModels backed
>> fully by UserFederationProvider, we will need to ensure that User ID
>> will be always same for same federated user "john" .  Like for example
>> instead of random UUID, the user ID will be generated from hash of
>> FederationProviderId+LDAPId . This will ensure that references to other
>> places by User ID will still work.
>>
>> Marek
>>
>> On 21/09/15 17:55, Bill Burke wrote:
>>>
>>>
>>> On 9/21/2015 9:04 AM, Marek Posolda wrote:
>>>>> You have to move this out of UserModel. UserModel may be backed 
>>>>> 99% by
>>>>> a UserFederationProvider.  In the near future, UserFederationProvider
>>>>> users may all sit in memory for only the lifetime of the session. 
>>>>> getFederated
>>>>>
>>>>>
>>>> Does it makes sense to issue offline token for the users, which are
>>>> valid just for the lifetime of the session?
>>>>
>>>
>>> The users aren't temporary, they are just stored in LDAP or something.
>>> So yes, it does make sense to issue offline tokens. The offline token
>>> storage will just need to store a reference to the user so it can
>>> rebuild it through our SPIs if needed.
>>>
>>
>