<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 July 2016 at 09:45, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 04/07/16 09:47, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><span style="font-size:12.8px">ScopeAggregatorProtocolMapper
sounds interesting, but I'm not quite sure how it would look
like to an end-user. </span>
<div><span style="font-size:12.8px"><br>
</span></div>
<div><span style="font-size:12.8px">* Are these managed on a
separate screen or on the protocol mappers screen? <br>
</span></div>
</div>
</blockquote></span>
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).</div></blockquote><div><br></div><div>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.</div><div><br></div><div>I think it would fit better on the scope tab. It could have two tabs "Default scope" and "Scopes" or something like that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-size:12.8px">* How do users define and
view scopes, including viewing what claims/mappers/roles are
associated with a scope?</span></div>
<div><span style="font-size:12.8px">* How does a user add/remove
claims, protocol mappers and roles to
a ScopeAggregatorProtocolMapper? </span><br>
</div>
</div>
</blockquote></span>
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.<br>
<br>
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", ...</div></blockquote><div><br></div><div>Sounds good</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-size:12.8px">* Do we provide one or more
built-in </span><span style="font-size:12.8px">ScopeAggregatorProtocolMapper
that are configurable? I assume so and that users don't have
to programatically define scopes.</span></div>
</div>
</blockquote></span>
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).<br>
<br>
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.</div></blockquote><div><br></div><div>SAML doesn't have this concept does it? If so it probably doesn't even make sense to show scope mappers for SAML clients.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="font-size:12.8px">* Can a scope resolve to
multiple ScopeAggregatorProtocolMapper?</span></div>
</div>
</blockquote></span>
Yes (see above)<span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><div><div class="h5"><br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 1 July 2016 at 21:45, Marek Posolda
<span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ok, I
wasn't also 100% keen about using role.<br>
<br>
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?<br>
<br>
Something like this:<br>
- 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.<br>
<br>
- You will be able to define "children" protocolMappers and
"children" roles in ScopeAggregatorProtocolMapper.<br>
<br>
- 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:<br>
client.getDefinedProtocolMappers() // all defined<br>
client.getProtocolMappers() // just subset of defined
(defacto root mappers)<br>
<br>
- 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.<br>
<br>
So then:<br>
-- 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"<br>
-- 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).<br>
<br>
- 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.<br>
<br>
- 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:<br>
1) user is member of the role<br>
2) client has scope for the role (so current "scope" tab in
clients will remain as is)<br>
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).<br>
<br>
So again, user won't see all children roles on consent
screen. Just the parent protocolMapper.<br>
<br>
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.<br>
<br>
- If some scope parameter is applicable for more clients, it
can be defined on clientTemplate.<br>
<br>
<br>
PS: I will be on holidays and back on next Thursday 7th
July. So sorry if I won't reply immediately to next mails.<br>
<br>
Mare
<div>
<div><br>
<br>
<br>
On 01/07/16 14:57, Pedro Igor Silva wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Reading all of this makes me think it would be
cleaner to introduce a<br>
separate scope concept ;)<br>
<br>
A user doesn't have a scope - a user has roles and
attributes. Re-using roles<br>
concept for the scope just makes it feel awkward and
retrofitted.<br>
</blockquote>
+10000<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>