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.