[keycloak-dev] Offline tokens - step 1

[Bill Burke]

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.
>>>>
>>>>
>>> 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.
>>
>

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