[keycloak-dev] Scope parameter support

[Stian Thorgersen]

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?
* 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?
* 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.
* Can a scope resolve to multiple ScopeAggregatorProtocolMapper?

On 1 July 2016 at 21:45, Marek Posolda <mposolda at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160704/c10d33d4/attachment.html