8:03 a.m.
On 4/23/2015 1:52 AM, Stian Thorgersen wrote:
Any comments on this?
----- Original Message -----
> From: "Stian Thorgersen" <stian(a)redhat.com>
> To: "keycloak dev" <keycloak-dev(a)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