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

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev