<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? </span></div><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><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><span style="font-size:12.8px">* Can a scope resolve to multiple ScopeAggregatorProtocolMapper?</span></div></div><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 class="HOEnZb"><div class="h5"><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>