I'm definitively leaning towards introducing a new concept called scopes,
rather than trying to shoehorn this into roles.
On 1 July 2016 at 14:29, Marek Posolda <mposolda(a)redhat.com> wrote:
On 30/06/16 21:42, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda(a)redhat.com>
>> To: keycloak-dev(a)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
>> role "client1/foo2" and protocolMapper for "firstName" and
> +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 /
>> 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
>> true. Then I will define "scope param values" : "bar" and
>> means that if someone uses parameter "scope=bar" or
>> scope=baz", then role "foo" will be applied to token. Otherwise
>> 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
> IMO, roles and scopes are separated concepts. Where scopes may also
implicate access to the roles granted to an user. Scopes have a pretty
> 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
So just scope "roles" may not be sufficient for fine-grained chose of
> 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
> related with a scope.
keycloak-dev mailing list