[keycloak-dev] Scope parameter support

Wed Jun 21 02:54:00 EDT 2017

Nothing new to report here. If someone wants to contribute it great, but I
doubt we'll find to do it ourselves anytime soon. Would be best to start a
new discussion around it if someone wants to contribute.

On 21 June 2017 at 02:06, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Hello folks,
>
> are the conclusions of this discussion regarding scope parameter support
> still current or are they already superseded by new insights?
>
> For completeness the JIRA issue for "Scope query parameter support":
> https://issues.jboss.org/browse/KEYCLOAK-349
>
> Cheers,
> Thomas
>
> 2016-07-11 12:13 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>>
>>
>> On 11 July 2016 at 09:35, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 11/07/16 08:22, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 8 July 2016 at 14:07, Marek Posolda <mposolda at redhat.com> wrote:
>>>
>>>> On 07/07/16 12:07, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 7 July 2016 at 09:45, Marek Posolda < <mposolda at redhat.com>
>>>> 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.
>>>>
>>>> Not sure which place is better. However I am maybe slightly more for
>>>> protocolMappers screen because:
>>>>
>>>> - 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 ;-)
>>>>
>>>
>>>>
>>>> - 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.
>>>> 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?
>>>>
>>>
>>> You lost me a bit here. I think I may have miss understood something you
>>> explained before.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> For example, if there is protocolMapper provider with id "foo" then
>>> angular will:
>>> - First look if there is special screen "protocol-mapper-detail_foo.html"
>>> .
>>> - 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.
>>>
>>> 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.
>>>
>>>
>>> Maybe it's time to do some mock screens or wire frames?
>>>
>>> +1
>>>
>>> or start prototyping and see how it goes? :)
>>>
>>
>> Prototyping is just a superior mock ;)
>>
>>
>>>
>>>
>>> Marek
>>>
>>>
>>>
>>>>
>>>>
>>>> Btv. Our current providerModel classes usually have something like:
>>>>
>>>> Map<String, String> config;
>>>>
>>>> on them. However for the aggregated mapper impl, it may be needed to
>>>> extend this to:
>>>>
>>>> Map<String, List<String>> config;
>>>>
>>>> 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:
>>>> a) The value at DB level will be just simple string with children
>>>> values divided by some delimiter (eg. "mapper123###mapper456###mapper789"
>>>> )
>>>> b) The value will be list at DB level with separate record for every
>>>> value (eg. 3 values like "mapper123" , "mapper456" , "mapper789" )
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>>>
>>>>> * 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.
>>>>
>>>> I don't think that SAML has something like scope parameter. At least I
>>>> am not aware of that :-)
>>>>
>>>> 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?
>>>>
>>>> Marek
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>
>>>>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>>>>
>>>>> Yes (see above)
>>>>>
>>>>> Marek
>>>>>
>>>>>
>>>>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda at redhat.com>
>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>