Dne 27.3.2018 v 16:14 Bill Burke napsal(a):
On Tue, Mar 27, 2018 at 2:53 AM, Marek Posolda
> 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
> 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.
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
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
* 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
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.
- 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
- 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
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