<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 July 2016 at 14:07, 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 07/07/16 12:07, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<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>
<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>
</div>
</blockquote></span>
Not sure which place is better. However I am maybe slightly more for
protocolMappers screen because:<br>
<br>
- It just looks a bit more intuitive to me if all the things, which
are represented at model/DB level by protocolMapper entity are also
in admin console grouped together on single place. But maybe it's
just me <span><span> ;-) </span></span></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"><br>
<br>
- For the aggregated mapper, you can select that "children" mappers
will be either simple mappers or other aggregated mappers. For
example for the "full-profile" mapper, you can select that it's
child is another aggregated mapper "profile" together with some
additional simple mappers like "first_name" or "last_name" . Hence
in the list of available mappers, you should be able to see both
simple and aggregated mappers. <br>
Isn't it then a bit confusing that you will see both the simple
mappers like "firstName" (which are configured in "mappers" tab)
together with aggregated mappers like "profile" (which are
configured under "scope/default scope" tab) together?<br></div></blockquote><div><br></div><div>You lost me a bit here. I think I may have miss understood something you explained before.</div><div><br></div><div>My assumption was that there are two separate things: regular mappers and scope mappers. Regular mappers are configured as before, while scope mappers are configured for each scope. So there would be separate screens in either case. Maybe I'm wrong here, but I could see a page that lists all scopes, then you can click on the scope to see what mappers are applied as well as what roles are applied.</div><div><br></div><div>Maybe it's time to do some mock screens or wire frames?</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">
<br>
<br>
Btv. Our current providerModel classes usually have something like:<br>
<br>
Map<String, String> config;<br>
<br>
on them. However for the aggregated mapper impl, it may be needed to
extend this to:<br>
<br>
Map<String, List<String>> config; <br>
<br>
as mapper will need to have the property with the list of children
mappers and property with the list of children roles. The question
is, how to represent it in DB? I can see possibilities like:<br>
a) The value at DB level will be just simple string with children
values divided by some delimiter (eg.
"mapper123###mapper456###mapper789" )<br>
b) The value will be list at DB level with separate record for every
value (eg. 3 values like "mapper123" , "mapper456" , "mapper789" )<br>
<br>
It seems the (b) is a bit harder for migration, but likely the more
proper way to address this? It looks like something to keep in mind
once we refactor to the "unified" providerModel table.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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><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><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>
</div>
</blockquote></span>
I don't think that SAML has something like scope parameter. At least
I am not aware of that <span><span> :-) </span></span><br>
<br>
However our SAML clients currently have "Scope" tab visible to map
which realm roles (or client roles) are allowed to be put into SAML
assertion. That works same like for OIDC clients and makes sense to
keep. I guess you meant to hide just the new sub-tab of the "Scope"
tab for configure scope parameter?<span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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><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><font color="#888888"><br>
<br>
Marek</font></span>
<div>
<div><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"></a><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>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>