[keycloak-dev] offline access tokens part 2

Tue Mar 27 14:55:19 EDT 2018

Dne 27.3.2018 v 16:14 Bill Burke napsal(a):
> On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda <mposolda at redhat.com> wrote:
>> Dne 27.3.2018 v 04:41 Bill Burke napsal(a):
>>> These are my thoughts for implementing offline access tokens:
>>>
>>> * offline access tokens MUST be validated.  This means that if they
>>> are used during bearer token requests, the service must validate the
>>> token with the token endpoint.
>>> * These tokens MUST be rejected by older keycloak clients as our
>>> adapters dont' have support for them.
>>> * offline access tokens will not be stored in the database.  Instead
>>> they will be JWEs or JWS that link to an offline user session. (our
>>> current offline access implementation).  They will be revokable just
>>> like any other offline session and in the same manner.  This makes the
>>> implementation simple.
>>>
>>> * There will be 4 modes for configuring clients
>>> - client automatically receives offline access tokens (maybe not
>>> include a refresh token in this case)
>>> - client may request an offline access token
>>> - client requires consent before providing an offline access token
>>> - client is not allowed to ask for offline access tokens (default)
>>>
>>> Any other thoughts on this?
>> How will client tells that it wants this offline token? Will it be some
>> special value of scope parameter like "scope=persistent_token" ?
>>
> Yeah, I think so.
>
>> I can imagine that issuing this token will be handled by protocol mapper?
>> Some protocolMapper implementation, which will change token expiration to 0
>> (which means infinity) and change token type to something like "persistent"
>> ?
>>
>> Once we have clientScopes in, it will be easily possible to ensure that this
>> protocolMapper is used just if "persistent_token" scope is used as
>> protocolMapper will be just configured on "persistent_token" client scope.
>> However the clientScopes PR will likely need to wait for few weeks or so...
>>
> I don't think it should be implemented as a protocol mapper, or as a
> regular access token.  #1 you'll still need to recognize that the
> client is requesting an offline access token because you'll need to
> create an offline user session.  #2, We want the offline access token
> to be as small as possible and for it to contain no information an
> attacker could use.  I would implement it as a JWE that contained a
> user session id and the scopes the client has been consented for.  #3
> You don't want to implement it as an access token as you want older
> Keycloak clients to reject them in bearer token requests.   Where
> protocol mappers would come in is when the client validates the token.
> In that case an unmarshalled id token or access token would be created
> with using the client scopes the token was minted for.
Ok

BTV. I've already did some JWE stuff and it's currently used for OAuth 
code. It's in "core" module and it's already in Keycloak master.

We discusssed with Pedro and Sebastian Schuster from community in the 
other thread, that it will be good to add "scope" as the builtin claim 
into our access token itself. That way, the refresh tokens and offline 
tokens (and I believe new persistent token too) will also contain 
"scope", as they inherit from AccessToken class. JIRA with some more 
context is https://issues.jboss.org/browse/KEYCLOAK-6883 . This is not 
yet done in my clientScope PR, but I think it will be quite easy addition.
>
> Question, when you create a client, and specify what scopes its
> constructed of, can you mark one or more "inherited" scopes as
> requiring consent?  Might be a great way to re-use scopes for clients
> that require consent.
Yes. If I understand correctly, this shouldn't be a problem.

ClientScope has on/off flag "Display On Consent Screen" . The client 
still has "Consent Required" flag. In case that client is marked as 
"Consent required", then consent screen will show all the clientScopes 
marked with "Display On Consent Screen". By default, all clientScopes 
has "Display On Consent Screen" switched to ON.

Note that when client itself doesn't have "Consent Required", the 
consent screen is never displayed. Same behaviour like in current master.
>
>
> So I think it woudl work like this.  I'm making guesses to how Client
> Scopes was implemented as I don't fully remember your presentation:
>
> * We create a built in "persistent-token" scope.  This is empty.  No
> protocol mappers, no nothing.
> * persistent access tokens are JWEs that contain a user session id and
> scopes client is allowed to access.
> * When a client is created in the admin console, the
> "persistent-token" scope is added as a default scope.  In this case,
> this means that the client should automatically get a persistent
> token.
> * If the client requires consent, then mark the "persistent-token"
> scope as requiring consent for that client
>
> * persistent tokens are created as a JWE that contains a user session
> id and scopes the client is allowed to access
> * When a persistent token is minted, it does the same offline user
> session logic that "offline access" does.
> * persisten tokens must be validated with the Keycloak token userinfo
> or token introspection endpoints depending on the level of information
> needed.
I think this workflow should work fine regarding client scopes.
>
> BTW, how long is a "few weeks"?  I won't be able to release
> openshift/kubernetes integration until I can add "allowed groups" to
> client scopes.  Access decisions are entirely group-membership based.
> If you're interested in more detail, read further:
I've just did rebase of the clientScopes PR with latest master. In 
theory, it can be merged very soon if it blocks you. What prevents it 
from merging is:
- One failed test in cross-dc after rebase. I've just checked that this 
is broken in current master and not related to the clientScopes PR. 
Created: https://issues.jboss.org/browse/KEYCLOAK-7017
- One approved review. It was reviewed only by Vlasta from QA team and 
he also fixed some issues and broken databases. I think Stian also 
wanted to review it. You are welcome to review as well. Sorry it's so 
big PR...
- Documentation - It's not documented yet and current documentation 
contains some references to client templates, which is now outdated. 
Also some screenshots likely need to be redone... I need to work on 
summit demo and don't have time to finish docs in next few weeks TBH.

IMO It's not a problem if clientScopes PR is merged in master and docs 
master is outdated for some time. However it will be bad IMO to release 
Keycloak with the outdated documentation. If next Keycloak beta can be 
postponed to second half of April, it should be fine. I should be able 
to spend time on docs before that. I think it will be like a day of work 
or so.

Marek
>
> When Openshift and kubernetes validate a token they call a validation
> endpoint that returns a username and group membership for that user.
> Never roles.  Kub/OS have roles, very specific roles, but access
> decisions are based on user-role and group-role bindings.  What's even
> more interesting is that users and groups are just strings to Kub/OS.
> You don't create a user or group, you just specify the username or
> group string when you create a role binding.  The kubernetes
> integration is actually ridiculously easy and took me like 2 hours.
> It required just implementing a special validation endpoint for
> keycloak tokens.
>
> Bill