<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Nice work Marko! </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> I had two (not big deal) questions. First, when you<br>
specify the --cache parameters as you did for SAML, could the cache file be omitted?<br>
<br>
For example: kcreg --cache -r saml-realm ...<br>
<br>
I was thinking that once you specified the realm name, the API will just<br>
look for ~/.keycloak/saml-realm.cache. It's just an idea</blockquote><div><br></div><div>We could maybe add this behaviour in addition to current behaviour. It's not enough to just specify a realm though, since server can also be different. For example: </div><div><br></div><div> # login as admin user in master realm on localhost using default cache file (~/.keycloak/kcreg.cache)</div><div> kcreg login -s <a href="http://localhost:8080/auth">http://localhost:8080/auth</a> -r master -u admin</div><div><br></div><div> # login as admin user in master realm on <a href="http://login.example.com">login.example.com</a> using a different cache file</div><div> kcreg --cache ~/.keycloak/example_com.cache login -s <a href="http://login.example.com">http://login.example.com</a> -r master -u admin</div><div><br></div><div><br></div><div>Using kcreg --cache -r master ... as above would default to the same file (~/.keycloak/master.cache) unless we also include server_endpoint in the file name e.g.: localhost_8080_auth_master.cache. But then - login command gets the server specified by user. Not so with other commands.</div><div><br></div><div>The current mechanism reads the server from the specified cache file (the server for current session it's stored inside a JSON):</div><div><br></div><div> kcreg --cache ~/.keycloak/localhost_8080_auth_master.cache get my_client</div><div><br></div><div><br></div><div>So your proposal is unable to determine the full name of the file - we need to know the server already to compose the file name:</div><div><br></div><div> kcreg --cache -r master get my_client</div><div><br></div><div>The above can resolve to ~/.keycloak/master.cache but doesn't have enough info to resolve to ~/.keycloak/localhost_8080_auth_master.cache.</div><div><br></div><div>If we also have to specify server the result is not worth the bother:</div><div><br></div><div> kcreg --cache -s <a href="http://localhost:8080/auth">http://localhost:8080/auth</a> -r master get my_client</div><div><br></div><div><br></div><div>Another thing - if we want to also support current behavior (which allows all the freedom and flexibility of choosing any location on the filesystem for the cache file) we would then need to treat additional argument to --cache as optional, which can quickly get tricky:</div><div><br></div><div>kcreg --cache login -r master ...<br></div><div><br></div><div>vs.<br></div><div><br></div><div>kcreg --cache /tmp/session.cache -x login ...</div><div><br></div><div>vs.</div><div><br></div><div>kcreg --cache -r master get ...</div><div><br></div><div><br></div><div>We could do that by checking if next argument begins with a '-' but that would disable usage of any filename starting with '-'. And we would have to treat it differently for login ...</div><div><br></div><div>The more I look at it, the more complex and tricky it gets to get it right.</div><div><br></div><div><br></div><div>One quite simple solution towards more ergonomic usage would be to simply differentiate whether the specified path is absolute or relative, and if relative we could default the directory to ~/.keycloak.</div><div><br></div><div>For example:</div><div><br></div><div>kcreg --cache master login -s <a href="http://localhost:8080/auth">http://localhost:8080/auth</a> -r master -u admin</div><div><br></div><div>This would generate the following cache file: ~/.keycloak/master.cache, and the folling command would use that file as well:</div><div><br></div><div>kcreg --cache master get my_client</div><div><br></div><div><br></div><div>The absolute names would be those starting with /, ~/ on unix, c:\, d:\ ... on Windows</div><div><br></div><div>This behaviour is easy to add.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Second question, is more like something to think if worth to take<br>
into consideration. Most of the examples that I saw, make use of<br>
username/password. But if the admin enables two factor authentication,<br>
she might be unable to use our client-reg CLI, or enforce weaken security only<br>
to make use of the CLI.<br>
<br>
Is OTP support planned for further iterations?</blockquote><div><br></div><div>I don't know how exactly OTP auth works under the hood, but if Stian says it's no problem and it's easy to implement then that's your answer :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div class="h5">
<br>
On 2016-07-21, Marko Strukelj wrote:<br>
> And if anyone wants to get their feet wet already:<br>
><br>
> <a href="https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool" rel="noreferrer" target="_blank">https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool</a><br>
><br>
><br>
> On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <<a href="mailto:sthorger@redhat.com">sthorger@redhat.com</a>><br>
> wrote:<br>
><br>
> > Great work Marko!<br>
> ><br>
> > As we didn't have time to go through feedback let's use this thread for<br>
> > it. Add your questions and comments here please.<br>
> ><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>
> ><br>
<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>
<br>
<br>
</div></div>--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
</blockquote></div><br></div></div>