<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 December 2015 at 16:31, Bill Burke <span dir="ltr">&lt;<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The last phase of client templates would be to allow defining<br>
configuration items in the client template that the client inherits.  I<br>
was going to implement it as an either or.  There will be a switch<br>
&quot;Inherit Template Configuration&quot;  If this is off, then config items are<br>
taken from the client, otherwise they are taken from the template.<br>
There would be no mix and match.<br></blockquote><div><br></div><div>What&#39;s the point in that? I can&#39;t see anyone wanting to create multiple clients with the same config.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
FYI, I&quot;m not sure I&#39;ll be able to finish this prior to our deadline of<br>
early January.  There&#39;s still a lot of JIRAs to do beyond this.<br>
<br>
This week though, I think I want to rework and simplify client creation<br>
a bit more.  Create client on the admin console would only require must<br>
needed config attributes:<br>
<br>
OIDC:<br>
Client ID<br>
Root URL<br>
Choose Client Template if wanted<br>
<br>
These would be the defaults:<br>
* Access type: public (pretty much covers any use)<br>
* enabled true<br>
* Redirect URIs would default to Root/*<br>
* Standard Flow true<br>
* Direct Grants false<br>
* Service Accounts false<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
SAML:<br>
Client Entity ID:<br>
SAML SP Endpoint (not required, can make it more fine grained)<br>
Choose client template if wanted<br>
<br>
* Sign Docs: true<br>
* Sign Assertions: false<br>
* Client Signature Required: true<br>
* Force POST BInding true<br>
* Front Channel logout: true<br>
* Force Name ID Format: false<br>
* Name ID Format username<br>
* Valid Redirect URIS renamed to Valid Assertion Consumer Service URIs<br>
* certs would be generated by default<br></blockquote><div><br></div><div>So you are proposing that create client and edit client screens are different? IMO that&#39;s not good. Instead we should use tabs to split the settings into multiple sections. From what you are proposing above I see that most folks would have to first create the client then immediately edit the client afterwards.</div><div><br></div><div>I&#39;d like refactoring and UX changes to be discussed properly prior to doing them.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I&#39;m also going to add a method to LoginProtocolFactory:<br>
<br>
setupDefaults(ClientModel).  When a client is created, this method would<br>
be called, then the defaults would be overriden if they are set in the<br>
ClientRepresentation.  Right now, all this default logic is in the admin<br>
console and I don&#39;t think it should be there.<br>
<span class="HOEnZb"><font color="#888888"><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>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</font></span></blockquote></div><br></div></div>