[keycloak-dev] client templates and default mappers

Stian Thorgersen sthorger at redhat.com
Thu Dec 17 08:50:12 EST 2015


On 17 December 2015 at 14:37, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 12/17/2015 3:54 AM, Stian Thorgersen wrote:
>
>>
>>
>> On 16 December 2015 at 14:19, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     On 15/12/15 18:26, Bill Burke wrote:
>>     > What to do with default mappers and clients and client templates?
>>     >
>>     > When you create a client, it automatically adds default mappers for
>> each
>>     > protocol.  Now with client teampltes, if you create a client and
>> specify
>>     > a client template when you create it, it will not add default
>> mappers to
>>     > the client.  Sound like right behavior?
>>     IMO yes. This also adds possibility that your client will be created
>>     with some builtin mappers removed by default.
>>     >
>>     > When creating a client template, should efault mappers be added to
>> the
>>     > temaplte automatically?  Or should the user have to manually add
>> them?
>>     IMO it's better if he needs to manually add them. He can already add
>>     builtin mappers very easily if he wants to, so doesn't sound like
>>     usability issue that default mappers are not there.
>>     >
>>     > The mappers tab of a client will have a link "view template mappers"
>>     > which will bring you to the template's mapper page.  You will be
>> able to
>>     > add additional mappers to your client, but you will not be able to
>>     > override a template's mappers.
>>     >
>>     > Sound cool enough?
>>     >
>>     I think yes.
>>
>>     Another possibility is that on client setup, there will be list of
>>     checkboxes with mappers inherited from the parent. And all the
>>     checkboxes (mappers) will be checked by default. Admin has possibility
>>     to uncheck some inherited mappers. That adds possibility for admin to
>>     remove some inherited mappers.
>>
>>     Is it sufficient to support just one client template for client? I
>> guess
>>     yes, but not sure...
>>
>>
>> Client templates would be useful when there's a set of standard claims
>> that a group of clients expects in a token. Allowing individual clients
>> to add/remove/override those standard claims makes little sense. I also
>> don't think there's a need for a client to be able to inherit from
>> multiple templates.
>>
>>
> Certainly makes sense for a client to be able to add additional claims.
> Removal and override are just too complicated to model in a UI and
> datamodel IMO.  It *would* make things easier if a Client Template is
> specified for a client the client cannot change config, add scopes, or add
> mappers.


I wrote that a bit quick. I didn't mean a client shouldn't be able to add,
that's the only thing it should be able to do IMO. It should not be able to
change/remove, not just from the complexity of modelling it, but also don't
think it's going to be the wanted behavior. If you add a claim to a group
of clients you expect it to be there for all clients.


>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151217/0cbcdb44/attachment-0001.html 


More information about the keycloak-dev mailing list