[keycloak-dev] Identity Brokering token storage and retrieval

[Bill Burke]

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?

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


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

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