<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 December 2015 at 14:37, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 12/17/2015 3:54 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On 16 December 2015 at 14:19, Marek Posolda <<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>>> wrote:<br>
<br>
On 15/12/15 18:26, Bill Burke wrote:<br>
> What to do with default mappers and clients and client templates?<br>
><br>
> When you create a client, it automatically adds default mappers for each<br>
> protocol. Now with client teampltes, if you create a client and specify<br>
> a client template when you create it, it will not add default mappers to<br>
> the client. Sound like right behavior?<br>
IMO yes. This also adds possibility that your client will be created<br>
with some builtin mappers removed by default.<br>
><br>
> When creating a client template, should efault mappers be added to the<br>
> temaplte automatically? Or should the user have to manually add them?<br>
IMO it's better if he needs to manually add them. He can already add<br>
builtin mappers very easily if he wants to, so doesn't sound like<br>
usability issue that default mappers are not there.<br>
><br>
> The mappers tab of a client will have a link "view template mappers"<br>
> which will bring you to the template's mapper page. You will be able to<br>
> add additional mappers to your client, but you will not be able to<br>
> override a template's mappers.<br>
><br>
> Sound cool enough?<br>
><br>
I think yes.<br>
<br>
Another possibility is that on client setup, there will be list of<br>
checkboxes with mappers inherited from the parent. And all the<br>
checkboxes (mappers) will be checked by default. Admin has possibility<br>
to uncheck some inherited mappers. That adds possibility for admin to<br>
remove some inherited mappers.<br>
<br>
Is it sufficient to support just one client template for client? I guess<br>
yes, but not sure...<br>
<br>
<br>
Client templates would be useful when there's a set of standard claims<br>
that a group of clients expects in a token. Allowing individual clients<br>
to add/remove/override those standard claims makes little sense. I also<br>
don't think there's a need for a client to be able to inherit from<br>
multiple templates.<br>
<br>
</div></div></blockquote>
<br>
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.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</div></div></blockquote></div><br></div></div>