[keycloak-dev] Initial client scopes PR

Thu Mar 15 08:13:17 EDT 2018

Is the long-term goal to make the "Scopes" tab for clients go away? Because currently it's a bit confusing both are there...

Best regards,
Sebastian

Mit freundlichen Grüßen / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn 

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Marek Posolda
Sent: Mittwoch, 14. März 2018 18:47
To: keycloak-dev at lists.jboss.org
Subject: [keycloak-dev] Initial client scopes PR

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

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev