[keycloak-dev] Scope parameter support

Marek Posolda mposolda at redhat.com
Fri Feb 9 08:30:18 EST 2018


Hi,

started looking at OAuth Scope parameter support. Wanted to clarify some 
things before start implementing:

- Client Scope will allow to group protocolMappers and Role Scope 
Mappings. Pretty similar to current Client Template


- Do we want to get rid of "Client templates" entirely and rename them 
to "Client Scopes" ? Or introduce Client scopes as separate thing in 
addition to client templates? My vote is to rename and get rid of client 
templates. It would mean get rid of new option "Login theme" from client 
template (client scope) then? As otherwise is unclear from which Client 
Scope will client inherit it (assuming client can be inherit from 
multiple Client Scopes, not just from single Client Template like is now).


- Client can inherit from more Client Scopes. I can see 2 groups:
-- Default Client Scopes - Those will be applied even if not requested 
by OIDC scope parameter
-- Optional Client Scopes - Those will be applied just if requested by 
OIDC scope parameter


- Do we still want to keep ProtocolMappers per client and 
Role-Scope-Mappings per client? I can imagine we get rid of them and let 
them to be completely inherited from "Client Scopes" . My vote is yes. 
Just afraid if there are some issues with it like:
-- backwards compatibility and migration -- But hope that's manageable
-- Option "Full Scope Allowed" from role scope mappings -- but that 
should be solvable too (See below)


- Consent screen:
-- Currently we have set of protocolMappers and set of roles on consent 
screen. I assume we want to get rid of this and have just single thing: 
Set of client scopes. Correct?
-- If yes, how to proceed with the protocolMappers and Role Scope 
Mappings, which are defined directly on the client? If we get rid of 
them (as I mentioned above), we don't have this issue. If we don't get 
rid of them, we can have something like "Default consent", which 
encapsulates all the protocolMappers and Role Scope Mappings declared 
directly on client. WDYT?


- Option "Is Consent Required" and "COnsent Text" on protocol mappers - 
Do we want to remove those? I think yes.


- Option "Full Scope Allowed" on clients and option "Scope Param 
Required" on roles.
-- I can imagine we remove both and replace them by having special 
builtin Client Scope, which will automatically have all the roles (all 
realm roles and all client roles of all clients) added to itself.
-- When new client is created, it will automatically have this builtin 
Client Scope added to itself - because currently newly created clients 
also have "Full Scope Allowed" ON by default.
-- When new role is created, it will be automatically added to that 
builtin Client Scope.
-- Admin has ability to remove the roles from this Client Scope. This 
defacto has same meaning like previously "Scope Param Required" flag on 
role, which is curently used for "offline_acces" role.


- I was thinking about creating some UI in admin console for "Scope 
Evaluating" . Admin will see effective roles and effective 
protocolMappers based on "scope" parameter he provides. I guess this 
doesn't have so big priority, but will be good to have IMO.


- UserConsentModel - do we remove roles and protocolMappers and replace 
them instead with Client Scopes? I think yes. Also change the 
"Applications" tab in account management accordingly and have the same 
"Client Scopes" like those, which were displayed on consent screen.


- Tokens - I think we still want to keep "Effective" claims and 
"effective" roles in tokens as is now? At least in first iteration.

WDYT?

Marek



More information about the keycloak-dev mailing list