[keycloak-dev] Initial client scopes PR

[Marek Posolda]

Hi,

I've finally send PR https://github.com/keycloak/keycloak/pull/5076 for 
the first iteration of client scopes. I will talk on tomorrow call about 
the details and still need to write some more automated tests. But I am 
seing PR now if someone wants to take a look.

Summary:

- Client Templates were renamed to "Client Scopes". Some things were 
removed from the client template admin console (EG. Theme setting added 
recently). Also I've removed some ClientTemplate model properties, which 
were never used. Client Scope still has list of protocol mappers and 
list of "Scopes" (Roles scope mappings).


- There is new tab "Client Scopes" on client. Here you can assign client 
scopes to client. Each client has 2 types of client scopes:
-- Default client scopes -- Those client scopes are automatically 
applied when login with the client. Their protocol mappers and "Role 
scope mappings" are always used.
-- Optional client scopes -- Those client scopes are applicable just for 
OIDC clients. They are used just if they are requested by "scope" 
parameter during login


- Under "Client scopes", there is new tab "Default Client Scopes" . This 
allows to specify "Realm default client scopes" and "Realm optional 
client scopes". The scopes configured here will be added as 
default/optional scopes to new clients. Client can override this (Remove 
those defaults and add some different client scopes). So it works 
similarly to Default Roles.


- Roles don't have "Scope Param Required" flag anymore. Protocol mappers 
don't have "Consent required" and "Consent text" anymore. Client scopes 
don't have "Full scope allowed" flag. But clients still have "Full scope 
allowed" flag for now and it's still ON by default for newly created 
clients.

- There are few builtin client scopes added to each realm. There are 4 
claims scopes defined in OIDC specification and those are added by 
default: "profile", "email", "address" and "phone" with the protocol 
mappers corresponding to the claims described in OIDC specification [1].
-- The "profile" and "email" are configured as default scopes and hence 
are automatically added to new clients.
-- The "phone" and "address" are configured as optional scopes by default.
-- The clients now doesn't have any protocolMappers added by default 
when they are created. I've added "profile" and "email" as default 
scopes due it's most close to the previous default protocolMappers we had.

- For SAML, there is "role_list" default client scope, containing just 1 
protocol mapper "role list". So both OIDC and SAML clients don't have 
any protocol mappers by default, it's driven by client scopes now by 
default.

- There is "offline_access" OIDC client scope, which is optional scope 
by default. This scope contains just "offline_access" realm role. Due 
the fact, that parameter "Scope Param Required" was removed from 
RoleModel, the "offline_access" role is now automatically available in 
tokens for clients with "Full Scope Allowed", even if no offline tokens 
was requsted. But I don't think it's big issue besides a bit bigger 
token. Same also already applies for uma_authorization and some other 
built-in roles. The fact, that offline token is requested is now driven 
by "offline_access" scope. But user should still have "offline_access" 
role to be able to receive offline token.

Consent changes:
- Consent screen now doesn't display protocolMappers (claims) and roles, 
but instead it displays just client scopes. So by default, the consent 
screen contains 2 items "User profile" and "Email address", which 
correspond to the "profile" and "email" OIDC scopes.

- There can be still the case, when client has some protocolMappers or 
role scope mappings defined on itself. So I've added flag "Display On 
Consent Screen" on clients (It's OFF by default) to specify if some 
message should be shown on consent screen about claims dedicated 
directly to client itself. It's useful especially when client doesn't 
have any client scopes as the consent screen wouldn't be displayed in 
that case.

- During this refactoring, I've tried to do some cleanup we discussed 
before, so I've removed protocolMappers and roles from clientSession. 
Instead I've added clientScopes to refresh token. During refreshing 
token, it's checked that user still has all the consents, which are in 
the refresh token. So in case that user revoked consents in the 
meantime, the token refresh will fail. ProtocolMappers and scoped roles 
are always re-computed from the clientScopes. So if for example another 
claim was added to scope "profile", it will automatically be applied 
after refreshed token. I don't see an issue with that. User approved on 
consent screen scope "profile" and he may not be concerned what 
claims/scoped roles are in profile.

- Migration: In the end I did not change existing clients and did not 
remove protocolMappers from them and didn't add default/optional client 
scopes to them. The only exception is "offline_access" profile, which is 
added as optional to all clients, which had scope to "offline_access" 
role. Consents are not migrated - again with the only exception being 
"offline_access" consent, so refreshing offline tokens from previous 
version still works. The new consent screen is something quite different 
than previous one, so makes sense to show it to users again when they 
want to login, even if they approved protocolMappers for the previous 
version.

Sorry for long email and long PR :) More tomorrow...


[1] http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

Marek