[keycloak-dev] PR for adding 'roles' and 'web-origins' client scopes

[Marek Posolda]

I've sent PR https://github.com/keycloak/keycloak/pull/5602 . Summary of 
changes:

- The roles and allowed-origins are not added automatically to the 
access tokens now. Instead of it, the PR introduces 2 default client 
scopes: 'roles' and 'web-origins' which adds them

- Client scope 'web-origins' adds allowed-origins to the access token 
similarly like it was before. So the only advantage is, that it is 
possible to remove clientScope/protocolMapper if you don't need web 
origins in the token

- Client scope 'roles' contains protocol mappers for add roles to the 
access tokens. By default, they are added to the claims "realm_access" 
and "resource_access" exactly as it was before. However it is easier to 
move to completely different claims. The PR doesn't introduce new 
protocol mapper implementation for roles, but uses the existing 
implementations UserRealmRoleMappingMapper and 
UserClientRoleMappingMapper. As a side-effect, it fixes some bug in 
those mappers claimed by many community users - 
https://issues.jboss.org/browse/KEYCLOAK-5259

- PR introduces new protocol mapper implementation 
AudienceResolveProtocolMapper, which adds audience of all the clients, 
for which at least one client role is available in the token. This is 
added by default to the 'roles' client scope

- There is new switch "Include in Token Scope" on the Client Scope. It 
is applicable only for OIDC clients. When it is off, the client scope is 
not added to the "scope" in the access token. It is used for both 
'roles' and 'web-origins' scopes, so those are not in the token by 
default now.

- There is some minor addition to ProtocolMapper SPI. Protocol mapper 
implementations has "priority" now. This is needed, so that it is 
ensured that for example we first "compute" the roles to be put in the 
token (including composite roles etc), then eventually add/move some 
roles through HardcodedRoleMapper or RoleNameMapper, then figure the 
audiences and finally move the roles to proper place in the token (which 
is not necessarily hardcoded to "realm_access" and "resource_access" 
claims as it was before).

- Migration is handled, so that 'roles' and 'web-origins' scopes are 
automatically added during migration and they are added to all the OIDC 
confidential/public clients.

WDYT?

Marek