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


On 12/17/2015 3:54 AM, Stian Thorgersen wrote:


On 16 December 2015 at 14:19, Marek Posolda <mposolda@redhat.com
<mailto:mposolda@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