<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 11 July 2016 at 09:35, 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 11/07/16 08:22, Stian Thorgersen
wrote:<br>
</div>
<blockquote type="cite">
<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>
<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"></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">
<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>
</div>
</div>
</blockquote></span>
I was thinking about ScopeAggregatedMapper just like about another
implementation of ProtocolMapper interface. No another special model
or special mapper type, which Keycloak needs to deal with. The
Keycloak (TokenManager) will treat like any other mapper, so will
just call "transformAccessToken" to it and ScopeAggregatedMapper
impl will delegate to other children mappers and apply roles.<br>
<br>
The difference is, that UI will need to be a bit special then for
other mappers. There is possibility that we will add the support
showing list of roles and protocolMappers to the directive
"kc-provider-config" . However it looks the better option might be
that particular protocolMapper implementation (or particular
provider implementation in general) has a way to override the
angular template with it's own UI if it wants to do it.<br>
<br>
For example, if there is protocolMapper provider with id "foo" then
angular will:<br>
- First look if there is special screen
"protocol-mapper-detail_foo.html" .<br>
- If the screen doesn't exist, it will fallback to default
"protocol-mapper-detail.html" screen with the "kc-provider-config"
directive for generic properties.<br>
<br>
For the protocolMapper, the scopeAggregatedMapper will have special
screen "protocol-mapper-detail_scope-aggregate.html" when all other
impls just use the generic screen like now. <span style="color:#000080;background-color:#e4e4ff;font-weight:bold"><br>
</span><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Maybe it's time to do some mock screens or wire frames?</div>
</div>
</div>
</div>
</blockquote></span>
+1<br>
<br>
or start prototyping and see how it goes? :)</div></blockquote><div><br></div><div>Prototyping is just a superior mock ;)</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="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"> <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><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><font color="#888888"><br>
<br>
Marek</font></span>
<div>
<div><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>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>