2:45 a.m.
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
screen?
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).
* 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
a ScopeAggregatorProtocolMapper?
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
user). 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 selected". 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 scopeAggregatorMappers.
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
number", ...
* Do we provide one or more built-in ScopeAggregatorProtocolMapper
that are configurable? I assume so and that users don't have to
programatically define scopes.
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.
* Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
Yes (see above)
Marek
On 1 July 2016 at 21:45, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@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 reuse protocolMappers SPI and have special impl
of protocolMapper, which is able to deal with scope parameter and
aggregate other "children" protocolMappers 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 be ignored if scope parameter value
with this name was not used.
- You will be able to define "children" protocolMappers and
"children" roles in ScopeAggregatorProtocolMapper.
- For each client (and clientTemplate), we will have many defined
protocolMappers, but just some subset of them are "root" mappers,
which are applied by default. The rest of mappers will be used
just as "children" of root mappers. So in client model, we might have:
client.getDefinedProtocolMappers() // all defined
client.getProtocolMappers() // just subset of defined (defacto
root mappers)
- 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 "profile" and it's children
mappers are : firstName, lastName, birthday.
So then:
-- user will send "scope=profile" . Then defacto all of
"firstName", "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. This 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 will 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 met).
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 just one children role (the current realm role
"offline_access"). The offline 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 be
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.
Mare
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. Re-using roles
concept for the scope just makes it feel awkward and
retrofitted.
+10000