[keycloak-dev] Scope parameter support

[Marek Posolda]

On 30/06/16 21:42, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, June 30, 2016 10:56:04 AM
>> Subject: [keycloak-dev] Scope parameter support
>>
>> IMO We will also need some more flexible way to specify how the value of
>> scope parameter will be mapped to roles and protocolMappers. For example
>> if I use "scope=foo", it can mean that I want realm role "foo1", client
>> role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.
> +1. I think I have mentioned something like that on a previous thread, where we should be able to build scopes from attributes (eg.: from user) or even compose a scope based on multiple attributes. The same concept applies to protocol mappers, just like you proposed.
>
>> I can see 2 possibilities:
>>
>> a) Configure allowed scope param separately per each role / protocolMapper
>>
>> If some role has "Scope param required" checked, you will have
>> possibility to configure list of available values of scope parameter,
>> which this role will be applied to. This will be configured per-each
>> role separately.
>>
>> Example: I have realm role "foo" . I check "scope param required" to
>> true. Then I will define "scope param values" :  "bar" and "baz". It
>> means that if someone uses parameter "scope=bar" or
>> scope=baz", then role "foo" will be applied to token. Otherwise it won't
>> be applied.
>>
>> Similarly it will be for protocolMappers. We will add switch "Scope
>> param required" to protocolMappers and we will use list of available
>> values of scope parameter, which is configured per each protocolMapper
>> separately.
> IMO, roles and scopes are separated concepts. Where scopes may also implicate access to the roles granted to an user. Scopes have a pretty broad meaning.
>
> With that in mind, don't you think that we could just have a scope "roles" ? Which could be used to ask for the roles associated with the user that the client is acting on behalf of ?
IMO it will be good that scope can be used to limit/extend the both 
protocolMappers and roles. For example we use "scope=offline_access" for 
offline tokens, so the role is applied just if it's included in scope 
parameter. Then user may also need to grant this role access on consent 
screen.

So just scope "roles" may not be sufficient for fine-grained chose of 
roles IMO.

Marek
>
> I think that the Protocol Mappers (for OIDC) provide pretty much everything you need. The missing part would be to make it capable of grouping other mappers. Actually, the concept behind a protocol mapper is pretty much
> related with a scope.