[keycloak-dev] offline access

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 10 April, 2015 4:24:40 PM
> Subject: Re: [keycloak-dev] offline access
> 
> 
> 
> On 4/10/2015 1:00 AM, Stian Thorgersen wrote:
> > Cloning into offline persistence is a good way to do it, I'm worried about
> > the complexity of it though. We'd need two separate user session stores
> > and do we look in both when there's a request for a user session? If we
> > don't look in both how do we make sure the persisted sessions are
> > re-loaded into the non-peristed store at startup time? That's even worse
> > in a cluster. I've implemented a hybrid store (where some stuff was kept
> > in jpa and others in-mem) it did end up as a bit of a cluster fuck though.
> >
> 
> I'm not worried about the complexity as we do something similar for user
> federation: UserFederationManager.  KeycloakSession also allows you to
> get access to internal storage, verses a logically federated view.
> 
> But...when I think about it more, maybe there are performance
> implications to my suggestion?  Would refresh token hit the DB
> unnecessarily?  Maybe this isn't an issue because refresh token requests
> rarely reference expired refresh tokens.
> 
> > I don't have an issue with admins managing offline sessions in the existing
> > way they manage sessions, actually that's probably the best way. We would
> > probably need to add support for logging out all or just non-offline when
> > logging out a user or application though.
> >
> > I don't like the idea of just having an offline column in account
> > management though as I think that's confusing to users. We need to at some
> > point give the account management some TLC as it looks pretty horrible and
> > there's some concepts that's probably confusing to most users. For example
> > sessions, logs and even worse federated identities. As a user I'd expect a
> > list of devices that I have logged in (Home computer, Work computer,
> > Mobile, etc.) and the ability to log that out. Then I'd expect a separate
> > list of applications/clients that can access my account where I can revoke
> > access to a specific client (which would also invalidate any offline
> > access). That's still perfectly achievable with either two approaches
> > though.
> >
> 
> I agree on account management needing some love.  I'd like to see us
> incorporate IP address demographics, then somebody could see where a
> login was from  i.e. USA, China, etc.  They don't need to see the IP
> address.
> 
> We will have to start logging user-agent header information in
> UserSession so that we can determine if the user was logged in via a
> device or not.  We'll also have to add a description to Applications.
> Otherwise the only designations we would be able to show is "Browser,
> Device, and Offline".
> 
> > Finally, we also need to introduce an offline role/scope that we can assign
> > to applications either through admin console, but it should also be
> > possible to use ?scope=offline which is what the OIDC spec mandates. This
> > would then work together with persisting consent/grants and the account
> > management would show what permissions each client has, including offline
> > access. There should be a single revoke access button for each client.
> > That would remove all persisted consents/grant for that client and also
> > remove all client sessions for that client. Doing that would also expire
> > all "offline" refresh tokens without requiring the user to manually manage
> > "client sessions".
> >
> > Another thing we should probably also add support to view/manage persisted
> > consents in the admin console. For example an admin should be able to see
> > what consents a user has given to what application and also revoke.
> >
> 
> We already know what the user has consented to.  This information is
> within the application's configured metadata: scope mappings, protocol
> mappers, etc.

Those can change over time though, which means that what a user previously consented to might be different to the clients "scope". Also, at some point we probably should introduce support for scope query param, which means each "login request" from an application could request different scopes. OIDC has a number of "scopes" that I'm pretty sure we need to support if we're going be a valid implementation.

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