[keycloak-dev] Identity Brokering token storage and retrieval

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 23 April, 2015 3:03:07 PM
> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
> 
> 
> 
> On 4/23/2015 1:52 AM, Stian Thorgersen wrote:
> > Any comments on this?
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, 20 April, 2015 9:08:13 AM
> >> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
> >>
> >> We've already discussed this, but didn't come to a conclusion.
> >>
> >> There's two separate use-cases to consider:
> >>
> >> 1. Authentication
> >> 2. Offline access
> >>
> >> For simplicity the examples below assumes OpenID Connect, but same logic
> >> applies to SAML.
> >>
> >>
> >> Authentication
> >> --------------
> >> In this case user authenticates using an external IdP. After the user has
> >> authenticated the access and refresh (if available) tokens are stored in
> >> user session. Tokens are automatically refreshed by Keycloak to support
> >> brokered log out. In this case an application can only retrieve an access
> >> token for the identity provider that was used to authenticate the user.
> >>
> 
> I don't know if SAML has refresh.  Half the social providers don't either.
> 
> I'm a bit wary of automatic background refresh.  Every active
> usersession would have to be polled periodically.  Don't know if that
> would be a big performance issue or not.  Maybe just do on-demand
> refresh checks?

I thought that was how the brokered logout worked. I agree that a automatic background refresh would be crazy.

How does the brokered logout actually work then?

> 
> >>
> >> Offline access
> >> --------------
> >> In this case we should add the option "offline access" to the provider
> >> config. When enabled we add "offline" to the requested scope. When a user
> >> first logs in or links through account mngmt we store the refresh token
> >> (aka
> >> "offline token") in the user store. As this is a long term token I don't
> >> see
> >> any problems using the user store for it. In this case an application can
> >> retrieve an access token for the identity provider that was used to
> >> authenticate the user, but also for an identity providers what have
> >> "offline
> >> access" enabled and there's an token store in the user store. One issue
> >> with
> >> this approach is that brokered log out doesn't work. A potential solution
> >> to
> >> that is that we only request offline access when linking the account, but
> >> during authentication don't add the offline scope and use the process from
> >> the first use-case.
> >>
> 
> If offline access is persisted, couldn't the external token still be
> stored in the persisted UserSession?

The offline token shouldn't be associated with a specific user session. It should be associated with a user.

> 
> 
> >>
> >> Token retrieval
> >> ---------------
> >> We add a "token service" client to Keycloak that has a "retrieve token"
> >> role
> >> for each provider. For an application to be able to retrieve the token the
> >> user has to have a role mapping on this role and the client has to have a
> >> scope on it as well. This results in using standard roles, scopes and
> >> consent screens instead of a different mechanism.
> >>
> 
> I implemented it as one master role for reading the external token.
> Wouldn't this be better?  Isn't one role per provider too fine grained?
>   Think about social, you'd have to assign 6-7 different roles to the
> user.  Although doing a role per provider would definitely make it
> easier to implement as I wouldn't have to implement the migration stuff
> I emailed about the other day.

I guess that's fine for now, no need to over complicate things if not necessary - we can just see if anyone complains and wants something more fine-grained.

> 
> BTW, I'm almost done with this. I ran into a problem testing where I
> uncovered a brokered logout bug and I've spent most of my time fixing that.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>