Re: [keycloak-dev] Scope parameter support

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > 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 "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 ?

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.