<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 11:40 AM, Marko Strukelj <span dir="ltr"><<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On 27 June 2016 at 21:26, John Dennis <span dir="ltr"><<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</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"><div><div>On 06/27/2016 07:48 AM, Marko Strukelj wrote:<br>
> I've started work on Client Registration CLI tool. As a first step, here<br>
> is a design document describing how I imagine the tool would be used.<br>
><br>
><br>
> <a href="https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing</a><br>
><br>
><br>
> I'll use this document as a spec / guide as I implement the client tool.<br>
><br>
> Within days I'll also send a link to initial ideas for Admin Client tool<br>
> which in principle should allow administrator to configure everything<br>
> that can otherwise be done through Admin Console.<br>
><br>
> Any feedback welcome.<br>
<br>
</div></div>FWIW we've already written a client registration tool for Keycloak. At<br>
the moment it is specifically targeted for SAML clients (SP, Service<br>
Provider) in Apache HTTPD but we have plans to extend it to OIDC.<br>
<br>
It is currently in Fedora and will also ship in OSP.<br>
<br>
It is hosted here:<br>
<a href="https://github.com/jdennis/keycloak-httpd-client-install" rel="noreferrer" target="_blank">https://github.com/jdennis/keycloak-httpd-client-install</a><br>
<br>
The man page for it (formatted for HTML) can be found here:<br>
<a href="https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html" rel="noreferrer" target="_blank">https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html</a><br>
<br>
The man page discusses 3 different ways you can authenticate and 2<br>
different ways client registration can be performed.<br>
<br>
I have a lot of experience with Keycloak client registration tools and<br>
have worked through many issues, I'm happy to share my experience.<br>
<br>
Here are some thoughts/issues you may want to take into account:<br>
<br>
* The tool must be capable of running without interactivity as part of a<br>
scripted installation task.<br>
<br>
* It should not depend on a home directory being available.<br>
<br>
* If a home directory is utilized how will you disambiguate any stored<br>
state belonging to a script that is run by different processes but under<br>
the same user (possibly simultaneously)? To clarify, many install tools<br>
run as the root user or some other admin user. Each invocation of these<br>
install tools can be run with entirely different parameters and may<br>
execute either in parallel or partially overlapping in time.<br></blockquote></div></div></div></div></div></blockquote><div><br></div></div></div><div>Maybe I should have included this link in the design document to make it clear to everyone what Client Registration this tool is for: <a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html</a><br></div><div><br></div><div>It's a REST API defined by specs, and is separate from Admin REST API.</div><div> </div><div>About using home directory, the way I see it - you either a) specify all the state when executing a command, or b) you have a mechanism that allows the concept of 'session' between command invocations.</div><div> </div><div>If you use the first approach (a) then on each invocation of the command you have to specify either username:password, or a token. The client registration specification defines workflow for Initial Access Tokens, and Registration Access Tokens, which require to automatically intercept a newly issued token after each CRUD operation, and save it for any subsequent operation on the same client resource. I can't see how this could be achieved by using the first approach.</div><div><br></div><div>For the second approach (b) you need a way to communicate 'session' state. The state we are saving are just tokens associated with current user or specific clients, or specific grants. Looks to me that if multiple parallel sessions are in collision about these tokens then the cli tool itself might be used the wrong way. Namely, once the client authenticates with a login, access token and refresh token are cached. Multiple client instances can use the same access token, and the same refresh token. A thing to maybe be careful about is just properly locking the file when making changes to it. For initial access token you have to explicitly add it, and assign it an alias - you can use any random value there if you want. For registration access token they are automatically associated with initial token they were initiated from - again there should be no collision.</div><div><br></div><div>What alternative mechanism would you suggest for storing 'session' info? We want to support Windows as well so it can't be Unix / Bash specific.</div><span class=""><div><br></div></span></div></div></div></blockquote><div> </div><div>Thinking a bit more about this, I think OpenShift Client solves this problem by allowing you to specify a path to <font face="monospace, monospace">.kubeconfig</font> file (via <font face="monospace, monospace">--credentials</font> or <font face="monospace, monospace">--config </font>argument) which I believe serves the same purpose as the proposed <font face="monospace, monospace">kc.cache</font> file.</div><div><br></div><div>So by adding something like <font face="monospace, monospace">--config PATH</font> or <font face="monospace, monospace">--credentials PATH</font> or <font face="monospace, monospace">--cachefile PATH</font> you can use a random file path for each 'session', and thus achieve clear separation.</div><div><br></div><div>For example:</div><div><br></div><div><span id="docs-internal-guid-8cdbe011-975f-6f8d-b439-f373b4fc2b39"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:12px;font-family:"Courier New";color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">$ kc login </span><span style="line-height:normal;font-size:12px;font-family:"Courier New";color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">-s </span><span style="line-height:normal;color:rgb(0,0,0);font-family:"Courier New";font-size:12px;white-space:pre-wrap;background-color:transparent"><a href="http://localhost:8080/auth">http://localhost:8080/auth</a> </span><span style="font-size:12px;font-family:"Courier New";color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">-r $REALM -u $USER -p $PASSWORD</span><span style="color:rgb(0,0,0);font-family:"Courier New";font-size:12px;white-space:pre-wrap;line-height:normal;background-color:transparent"> </span><span style="color:rgb(0,0,0);font-family:"Courier New";font-size:12px;white-space:pre-wrap;line-height:1.38;background-color:transparent">--config /tmp/.kc_$SESSION.cfg</span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:12px;font-family:"Courier New";color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent">$ kc create --config /tmp/.kc_$SESSION.cfg -f /tmp/.kc_client_$SESSION.json</span></p><div><span style="font-size:12px;font-family:"Courier New";color:rgb(0,0,0);vertical-align:baseline;white-space:pre-wrap;background-color:transparent"><br></span></div><div><br></div></span></div></div></div></div>