[keycloak-dev] Scope parameter support

[Stian Thorgersen]

On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:

> 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).
>

Removing "Login theme" from client template is fine.

Client templates do have a nice benefit of allowing defining some protocol
mappers and scope that is shared between clients. That can probably be done
by having the option to set a default scope for a client perhaps?


>
>
> - 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
>

For default client scope, is there global defaults as well as client
defaults?


>
>
> - 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)
>

Not sure about this one. Client scopes can do it all probably, but I think
we'd have to address usability here. Say all I want to do is to add a
protocol mapper to add a single claim to the token for a client then I
don't want to have to:

* Create scope
* Add protocol mapper
* Configure client to set default scope

Then I also have to somehow find the client scopes that are only used by a
single client.


>
>
> - 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?
>

Would make a lot of sense to have a single place to define what is shown on
the consent screen. Client scopes is the place to do it.


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

+1 Not sure how that looks like for backwards compatibility though


>
>
> - 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.
>

The builtin client scope sounds like a good idea, the UI to evaluate also.
Actually I think the UI may be important to be able to easily review how a
token would look like.


>
>
> - 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.
>

+1


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

Do we perhaps need to introduce revisions for client scopes instead? That
way we can just track the scope + version for a token.


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