Hi Marek,
thanks again for your answer.
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" .
I have gone further now and used the script mapper below. It takes the
information from "resource-access" and copies each role to the "scope"
claim.
I think this is ok, because the "scope" claim in the access token does not mean
"client scope" anymore, but "rights associated with this token". This
seems to
be supported by RFC 6749, sections 3.3. and 10.3.
This is also the very same thing Auth0 does:
https://auth0.com/docs/architecture-scenarios/spa-api/part-2#create-a-rul...
.
Something like this might be useful as a builtin mapper I think. When looking
at other people's solutions to the problem of creating a scope restricted by
user permissions this mapper would have solved their problems.
var scopes = token.scope.split(" ");
var resourceAccess = token.getResourceAccess();
for (var resourceKey in resourceAccess) {
var roles = resourceAccess[resourceKey].getRoles().toArray();
for (var i = 0; i < roles.length; i++) {
scopes.push(resourceKey + ":" + roles[i]);
}
}
scopes.join(" ");
The only downside to this is that "roles"/"client roles" in the UI are
really
something like "permissions"/"scopes" now.
On a sidenote I also had to write a mapper like this to get multiple audiences
into my access token:
var aud = java.lang.reflect.Array.newInstance(java.lang.String.class, 3);
aud[0] = "client0";
aud[1] = "client1";
aud[2] = "client2";
aud;
This was necessary, because I couldn't really find any libraries that support
token exchange. "client0" actually requests the token, but it does not only
use this token for itself, but also to call "client1" and "client2".
Best,
-Matthias