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