On 7 July 2016 at 09:45, Marek Posolda <mposolda(a)redhat.com> wrote:
On 04/07/16 09:47, Stian Thorgersen wrote:
ScopeAggregatorProtocolMapper sounds interesting, but I'm not quite sure
how it would look like to an end-user.
* Are these managed on a separate screen or on the protocol mappers
I am thinking about the protocolMappers screen. Just add another "type" of
protocolMapper. This means that we don't need to add another
concept/modelType just for scope parameter, but still we can easily
filter/view the available mappers of type 'scope aggregator' (on the screen
with list of all protocolMappers).
Not quite sure I see why it should be on the protocol mappers screen. As
it's a separate type of mapper as well the UI to define them would be
different I'm not sure I see why it can't be a separate screen.
I think it would fit better on the scope tab. It could have two tabs
"Default scope" and "Scopes" or something like that.
* How do users define and view scopes, including viewing what
claims/mappers/roles are associated with a scope?
* How does a user add/remove claims, protocol mappers and roles to
I am thinking that for roles, you will select the roles in same way, like
it's in current "Scopes" tab of client (or "role mappings" tab of
Probably very similar UI can be used for selecting "children" mappers of
current protocolMapper though? Something like "Available mappers" and
"Assigned mappers" and buttons like "Add selected" and "Remove
Also similarly like for roles, you can view in "Effective mappers" the list
of all effective mappers in case that you have more composed aggregated
For example, if you have mapper for scope parameter "full-profile", which
will have children mappers, that will point to other scope aggregated
mappers : "profile" , "email" and "phone". Hence in
"Effective mappers" for
"full-profile" you will see all the descendants, not just the direct
children. So you will see also all the simple attribute mappers like
"firstName", "lastName", "birthday", "phone
* Do we provide one or more built-in ScopeAggregatorProtocolMapper that
are configurable? I assume so and that users don't have to programatically
Yes. I think that we should provide those built-in, which are specified by
OIDC specification. Which is "profile" , "email" , "phone"
, "address". And
we will need to define mappers for all their simple attributes (
"birthday", "gender" , ...) . Those simple mappers like
"birthday" won't be
root mappers by default, so they won't be applied unless the scope
parameter is used (for their parent scopeAggregatorMapper).
For backwards compatibility, we will still use the same 'simple' mappers
like now ( username, email, full name, family name, given name) and they
will be added to token by default. The scopeAggregator mappers (and their
corresponding children) will be applied just if the scope parameter with
corresponding value will be used.
SAML doesn't have this concept does it? If so it probably doesn't even make
sense to show scope mappers for SAML clients.
> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
> Yes (see above)
> On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com> wrote:
>> Ok, I wasn't also 100% keen about using role.
>> Thinking also about what Pedro mentioned before about protocol mappers.
>> So I wonder that instead of introduce new "scope" concept, we just
>> protocolMappers SPI and have special impl of protocolMapper, which is able
>> to deal with scope parameter and aggregate other "children"
>> and roles?
>> Something like this:
>> - There will be new ProtocolMapper implementation like
>> ScopeAggregatorProtocolMapper. You will define value of scope parameter
>> (eg. "photo" ) in the configuration of this protocolMapper. Mapper will
>> ignored if scope parameter value with this name was not used.
>> - You will be able to define "children" protocolMappers and
>> roles in ScopeAggregatorProtocolMapper.
>> - For each client (and clientTemplate), we will have many defined
>> protocolMappers, but just some subset of them are "root" mappers, which
>> applied by default. The rest of mappers will be used just as "children"
>> root mappers. So in client model, we might have:
>> client.getDefinedProtocolMappers() // all defined
>> client.getProtocolMappers() // just subset of defined (defacto root
>> - For example: client will have defined protocolMappers: firstName,
>> lastName, birthday, profile, email. Just "profile" and
"email" will be root
>> mappers. And "profile" is ScopeAggregatorMapper for scope value
>> and it's children mappers are : firstName, lastName, birthday.
>> So then:
>> -- user will send "scope=profile" . Then defacto all of
>> "lastName", "birthday", "email" claims will be
included in token. On
>> consent screen will be just "Profile" and "Email"
>> -- user won't send "scope=profile" . Then defacto just
"email" claim will
>> be included (So for this example, email is always included even if not
>> specified by scope parameter).
>> - With this concept, we are able to aggregate many various claims into
>> single value of "scope" and on the consent screen have just the roots.
>> would fit well for the default scope values mentioned by OIDC specs. We are
>> also able to define mappers (claims), which will be always available even
>> if not specified by scope parameter.
>> - For the roles, I am not 100% sure whether to include them into the
>> concept or not? However it seems to me that rather yes. The particular role
>> will be applied into token just if all of those 3 conditions are met:
>> 1) user is member of the role
>> 2) client has scope for the role (so current "scope" tab in clients
>> remain as is)
>> 3) if role has scopePAramRequired=true, then it must be included in some
>> mapper (in other words, those roles are not included directly in
>> clientSession.getRoles , but it's the responsibility of
>> ScopeAggregatorProtocolMapper to add them into token if conditions 1+2 are
>> So again, user won't see all children roles on consent screen. Just the
>> parent protocolMapper.
>> This will work fine with "scope=offline_access" . There will be
>> protocolMapper for "offline_access" parameter, which will aggregate
>> one children role (the current realm role "offline_access"). The
>> token will be issued just if accessToken will have "offline_access"
>> permission. So if some client, doesn't need offline tokens, it can just
>> remove "offline_access" protocolMapper. Also if some user shouldn't
>> allowed to request offline tokens, admin can remove him from the
>> "offline_access" role.
>> - If some scope parameter is applicable for more clients, it can be
>> defined on clientTemplate.
>> PS: I will be on holidays and back on next Thursday 7th July. So sorry if
>> I won't reply immediately to next mails.
>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>> Reading all of this makes me think it would be cleaner to introduce a
>>>> separate scope concept ;)
>>>> A user doesn't have a scope - a user has roles and attributes.
>>>> concept for the scope just makes it feel awkward and retrofitted.