[keycloak-dev] Scope parameter support

Mon Jul 11 06:13:03 EDT 2016

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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160711/efbcbeb9/attachment-0001.html 