Re: [keycloak-user] Client scopes not checked?
On 20/06/18 13:36, Matthias Kesternich wrote:
> This leads me to my next question: If I want to return only the
scopes that
> a user actually may acquire, how do I do this in Keycloak? Do I use the
> "Authorization" tab and configure appropriate policies? Do I write a
custom
> mapper that overwrites the default "scope" value? I'm going to
experiment
> with this anyways, but I'd like to know if I'm abusing the wrong machinery
> to achieve this goal.
So I experimented a bit and it seems I can just use a "User Client Role"
mapper
that adds the roles/permissions to the token. This is much easier than the full
UMA thing under "Authorization". There seem to be almost no working python
clients for UMA as well.
I am also probably going to separate "scope" and "permissions".
I'm realizing
that "scope" means "the client is allowed to access this and that"
while
"permissions" means "the user is allowed to access this and that".
This understanding seems to be verified by
https://stackoverflow.com/questions/48351332/oauth-scopes-and-application...
.
Yes, exactly. The "scope" is "the client is allowed to access this
and
that" . In other words, if you create client scope "admin-write" and you
add it as default client scope to the client "foo", then access token
issued for client "foo" will always contain scope "admin-write" .
Regardless of the roles which user actually has.
One more note: Access token already contains the roles available to user
by default. You can see claims "realm-access" and "resource-access"
inside access token. Which you can doublecheck in "Evaluate" tab of
client. Right now, we're adding those claims "realm-access" and
"resource-access" into the token automatically, but we want to add
protocolMapper to add them just "on demand" .
The "User Client Role" protocol mapper is needed just if you want roles
in the access token in some different format, than built-in claims
"realm-access" and "resource-access" use. This was the case just for
some 3rd party OIDC adapters (AFAIK it was Apache mod-auth-oidc, which
was the original reason why "User Client Role" protocolMapper was
developed and contributed by our community).
Marek
Does the solution using "User Client Role" make any sense to you?
Best,
-Matthias