[keycloak-dev] Scope parameter support
Marek Posolda
mposolda at redhat.com
Mon Jul 11 03:35:04 EDT 2016
On 11/07/16 08:22, Stian Thorgersen wrote:
>
>
> On 8 July 2016 at 14:07, Marek Posolda <mposolda at redhat.com
> <mailto: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
>> <mailto: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? :)
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
>>> <mailto: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/ded51fc5/attachment-0001.html
More information about the keycloak-dev
mailing list