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":
2016-07-11 12:13 GMT+02:00 Stian Thorgersen <sthorger(a)redhat.com>:
On 11 July 2016 at 09:35, Marek Posolda <mposolda(a)redhat.com> wrote:
> On 11/07/16 08:22, Stian Thorgersen wrote:
> On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com> wrote:
>> On 07/07/16 12:07, Stian Thorgersen wrote:
>> On 7 July 2016 at 09:45, Marek Posolda < <mposolda(a)redhat.com>
>> mposolda(a)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
>>> I am thinking about the protocolMappers screen. Just add another
>>> 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
>>> 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
>> be either simple mappers or other aggregated mappers. For example for the
>> "full-profile" mapper, you can select that it's child is another
>> mapper "profile" together with some additional simple mappers like
>> "first_name" or "last_name" . Hence in the list of available
>> 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)
>> 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
> 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?
> or start prototyping and see how it goes? :)
Prototyping is just a superior mock ;)
>> 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" ,
>> 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
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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
>> 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
>>> * Can a scope resolve to multiple ScopeAggregatorProtocolMapper?
>>> Yes (see above)
>>> On 1 July 2016 at 21:45, Marek Posolda < <mposolda(a)redhat.com>
>>> mposolda(a)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
>>>> able to deal with scope parameter and aggregate other
>>>> 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
>>>> Mapper will be ignored if scope parameter value with this name was not
>>>> - You will be able to define "children" protocolMappers and
>>>> 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
>>>> root mappers. So in client model, we might have:
>>>> client.getDefinedProtocolMappers() // all defined
>>>> client.getProtocolMappers() // just subset of defined (defacto root
>>>> - 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
>>>> and it's children mappers are : firstName, lastName, birthday.
>>>> So then:
>>>> -- user will send "scope=profile" . Then defacto all of
>>>> "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
>>>> will be included (So for this example, email is always included even if
>>>> 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
>>>> would fit well for the default scope values mentioned by OIDC specs. We
>>>> also able to define mappers (claims), which will be always available
>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>>> protocolMapper for "offline_access" parameter, which will
>>>> one children role (the current realm role "offline_access").
>>>> token will be issued just if accessToken will have
>>>> permission. So if some client, doesn't need offline tokens, it can
>>>> remove "offline_access" protocolMapper. Also if some user
>>>> 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.
>>>> On 01/07/16 14:57, Pedro Igor Silva wrote:
>>>>> Reading all of this makes me think it would be cleaner to introduce
>>>>>> separate scope concept ;)
>>>>>> A user doesn't have a scope - a user has roles and
>>>>>> Re-using roles
>>>>>> concept for the scope just makes it feel awkward and
keycloak-dev mailing list