[keycloak-dev] Offline tokens - step 1

[Stian Thorgersen]

On 22 September 2015 at 08:44, Marek Posolda <mposolda at redhat.com> 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.
>

+1


>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150922/2987f540/attachment.html