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

[Marek Posolda]

Fixed test failures in the PR. Should be ready to review. Docs PR is: 
https://github.com/keycloak/keycloak-documentation/pull/487

Marek

On 02/10/18 21:25, Marek Posolda wrote:
> 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
>