[keycloak-dev] Scope parameter support

[Bill Burke]

* Clients should retain protocol mappers and scope for backward
compatibility.  A client is itself a scope, IMO.
* Client Scopes should not have "full scope allowed" flag, but clients
should be able to set this flag.
* Groups should be something that can be added to a scope like roles are.
* Should be a separate "Default Scopes" tab like we have for default
roles/groups.  Defaults scopes are added to new clients, not linked.
This is so that we have backward compatibility and clients can remove
a default if it doesn't want it.




On Mon, Feb 12, 2018 at 3:49 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat