Re: [keycloak-dev] Scope parameter support

On 11 July 2016 at 09:35, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 11/07/16 08:22, Stian Thorgersen wrote: > > > > On 8 July 2016 at 14:07, Marek Posolda <mposolda(a)redhat.com&gt; wrote: > >> On 07/07/16 12:07, Stian Thorgersen wrote: >> >> >> >> On 7 July 2016 at 09:45, Marek Posolda < <mposolda(a)redhat.com&gt; >> mposolda(a)redhat.com&gt; 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(a)redhat.com&gt; >>> mposolda(a)redhat.com&gt; 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev