[keycloak-dev] Scope parameter support

Thu Jul 7 06:07:58 EDT 2016

On 7 July 2016 at 09:45, Marek Posolda <mposolda at redhat.com> wrote:

> On 04/07/16 09:47, Stian Thorgersen wrote:
>
> 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?
>
> 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).
>

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.

I think it would fit better on the scope tab. It could have two tabs
"Default scope" and "Scopes" or something like that.

>
> * 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?
>
> 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.
>
> 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", ...
>

Sounds good

>
> * 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.
>
> 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).
>
> 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.
>

SAML doesn't have this concept does it? If so it probably doesn't even make
sense to show scope mappers for SAML clients.

>
>

> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>
> Yes (see above)
>
> Marek
>
>
> 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/20160707/858735df/attachment-0001.html 