<div dir="ltr">The encryption support in Travis isn&#39;t that so you can encrypt sensitive details that goes into .travis.yaml which is public through the repo?</div><div class="gmail_extra"><br><div class="gmail_quote">On 30 June 2016 at 06:52, Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@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"><div dir="ltr">I don&#39;t see the need for that. For the client registration CLI we will support initial access tokens as well as service accounts with pub/priv key authentication. For admin cli we&#39;ll support service accounts. No one should be using username/password combined with automated jobs.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 29 June 2016 at 21:49, Bruno Oliveira <span dir="ltr">&lt;<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I&#39;m not sure if it&#39;s part of the scope for now. But<br>
thinking about situations where you have to automate jobs plus provide<br>
credentials without exposing them.<br>
<br>
My suggestion, even if it&#39;s not part of the scope for now is to encrypt it,<br>
like travis does[1]. I know that our plan is to deal of access token,<br>
but would be nice to not expose credentials not even a single time.<br>
<br>
<br>
[1] - <a href="https://docs.travis-ci.com/user/encryption-keys/" rel="noreferrer" target="_blank">https://docs.travis-ci.com/user/encryption-keys/</a><br>
<div><div><br>
On 2016-06-29, Stian Thorgersen wrote:<br>
&gt; On 28 June 2016 at 11:40, Marko Strukelj &lt;<a href="mailto:mstrukel@redhat.com" target="_blank">mstrukel@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On 27 June 2016 at 21:26, John Dennis &lt;<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; On 06/27/2016 07:48 AM, Marko Strukelj wrote:<br>
&gt; &gt;&gt;&gt; &gt; I&#39;ve started work on Client Registration CLI tool. As a first step,<br>
&gt; &gt;&gt;&gt; here<br>
&gt; &gt;&gt;&gt; &gt; is a design document describing how I imagine the tool would be used.<br>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; <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>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; &gt; I&#39;ll use this document as a spec / guide as I implement the client<br>
&gt; &gt;&gt;&gt; tool.<br>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; &gt; Within days I&#39;ll also send a link to initial ideas for Admin Client<br>
&gt; &gt;&gt;&gt; tool<br>
&gt; &gt;&gt;&gt; &gt; which in principle should allow administrator to configure everything<br>
&gt; &gt;&gt;&gt; &gt; that can otherwise be done through Admin Console.<br>
&gt; &gt;&gt;&gt; &gt;<br>
&gt; &gt;&gt;&gt; &gt; Any feedback welcome.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; FWIW we&#39;ve already written a client registration tool for Keycloak. At<br>
&gt; &gt;&gt;&gt; the moment it is specifically targeted for SAML clients (SP, Service<br>
&gt; &gt;&gt;&gt; Provider) in Apache HTTPD but we have plans to extend it to OIDC.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; It is currently in Fedora and will also ship in OSP.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; It is hosted here:<br>
&gt; &gt;&gt;&gt; <a href="https://github.com/jdennis/keycloak-httpd-client-install" rel="noreferrer" target="_blank">https://github.com/jdennis/keycloak-httpd-client-install</a><br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; The man page for it (formatted for HTML) can be found here:<br>
&gt; &gt;&gt;&gt; <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>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; The man page discusses 3 different ways you can authenticate and 2<br>
&gt; &gt;&gt;&gt; different ways client registration can be performed.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; I have a lot of experience with Keycloak client registration tools and<br>
&gt; &gt;&gt;&gt; have worked through many issues, I&#39;m happy to share my experience.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Here are some thoughts/issues you may want to take into account:<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * The tool must be capable of running without interactivity as part of a<br>
&gt; &gt;&gt;&gt; scripted installation task.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * It should not depend on a home directory being available.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * If a home directory is utilized how will you disambiguate any stored<br>
&gt; &gt;&gt;&gt; state belonging to a script that is run by different processes but under<br>
&gt; &gt;&gt;&gt; the same user (possibly simultaneously)? To clarify, many install tools<br>
&gt; &gt;&gt;&gt; run as the root user or some other admin user. Each invocation of these<br>
&gt; &gt;&gt;&gt; install tools can be run with entirely different parameters and may<br>
&gt; &gt;&gt;&gt; execute either in parallel or partially overlapping in time.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt; Maybe I should have included this link in the design document to make it<br>
&gt; &gt; clear to everyone what Client Registration this tool is for:<br>
&gt; &gt; <a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html" rel="noreferrer" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html</a><br>
&gt; &gt;<br>
&gt; &gt; It&#39;s a REST API defined by specs, and is separate from Admin REST API.<br>
&gt; &gt;<br>
&gt; &gt; About using home directory, the way I see it - you either a) specify all<br>
&gt; &gt; the state when executing a command, or b) you have a mechanism that allows<br>
&gt; &gt; the concept of &#39;session&#39; between command invocations.<br>
&gt; &gt;<br>
&gt; &gt; If you use the first approach (a) then on each invocation of the command<br>
&gt; &gt; you have to specify either username:password, or a token. The client<br>
&gt; &gt; registration specification defines workflow for Initial Access Tokens, and<br>
&gt; &gt; Registration Access Tokens, which require to automatically intercept a<br>
&gt; &gt; newly issued token after each CRUD operation, and save it for any<br>
&gt; &gt; subsequent operation on the same client resource. I can&#39;t see how this<br>
&gt; &gt; could be achieved by using the first approach.<br>
&gt; &gt;<br>
&gt; &gt; For the second approach (b) you need a way to communicate &#39;session&#39; state.<br>
&gt; &gt; The state we are saving are just tokens associated with current user or<br>
&gt; &gt; specific clients, or specific grants. Looks to me that if multiple parallel<br>
&gt; &gt; sessions are in collision about these tokens then the cli tool itself might<br>
&gt; &gt; be used the wrong way. Namely, once the client authenticates with a login,<br>
&gt; &gt; access token and refresh token are cached. Multiple client instances can<br>
&gt; &gt; use the same access token, and the same refresh token. A thing to maybe be<br>
&gt; &gt; careful about is just properly locking the file when making changes to it.<br>
&gt; &gt; For initial access token you have to explicitly add it, and assign it an<br>
&gt; &gt; alias - you can use any random value there if you want. For registration<br>
&gt; &gt; access token they are automatically associated with initial token they were<br>
&gt; &gt; initiated from - again there should be no collision.<br>
&gt; &gt;<br>
&gt;<br>
&gt; I like the option to have two approaches as there are two use-cases. One is<br>
&gt; manually registering for example during development or when manually<br>
&gt; configuring an application to use Keycloak. Another is scripted. Even for<br>
&gt; scripted you may quite likely want to just add service account credentials<br>
&gt; or initial access token directly to ~/.keycloak/ rather than pass these to<br>
&gt; the commands.<br>
&gt;<br>
&gt; Registration access tokens are associated with a client, not an initial<br>
&gt; access token. Also, remember the registration access token is changed on<br>
&gt; updates.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; What alternative mechanism would you suggest for storing &#39;session&#39; info?<br>
&gt; &gt; We want to support Windows as well so it can&#39;t be Unix / Bash specific.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; * The tool should be idempotent.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * You suggest storing tokens in a cache, how do you plan on handling the<br>
&gt; &gt;&gt;&gt; case where a token expires before all operations are complete?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * We also initially took the approach of caching tokens but discovered<br>
&gt; &gt;&gt;&gt; the complexity did not justify the minimal cost of obtaining a new token<br>
&gt; &gt;&gt;&gt; for each invocation. This greatly simplified the code with very little<br>
&gt; &gt;&gt;&gt; performance impact.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * You do not mention what type of client you&#39;re registering. I&#39;m<br>
&gt; &gt;&gt;&gt; assuming it&#39;s OpenID but SAML clients (SP) are equally important. The<br>
&gt; &gt;&gt;&gt; tool must be able to handle both.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Marko is probably referring to the Keycloak client representation, which<br>
&gt; &gt;&gt; can be either OpenID or SAML. However, we also need to support OpenID<br>
&gt; &gt;&gt; Connect client descriptions as well as SAML entity descriptors as both are<br>
&gt; &gt;&gt; supported by client reg services.<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; The CLI needs to know which of the client registration providers (REST<br>
&gt; &gt; endpoints) to use - there are four as described in the Client Registration<br>
&gt; &gt; documentation (<br>
&gt; &gt; <a href="http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html" rel="noreferrer" target="_blank">http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html</a><br>
&gt; &gt; )<br>
&gt; &gt;<br>
&gt; &gt; Ideally the input format of the file could be recognised as only<br>
&gt; &gt; appropriate for one of these providers, and the correct provider then<br>
&gt; &gt; automatically used. But maybe we need a way to explicitly tell the tool<br>
&gt; &gt; what provider to use. For example:<br>
&gt; &gt;<br>
&gt; &gt; kc new --type default --name test-app --enabled true --base-url<br>
&gt; &gt; <a href="http://localhost:8480/test-app" rel="noreferrer" target="_blank">http://localhost:8480/test-app</a> --redirect-uri &#39;<br>
&gt; &gt; <a href="http://localhost:8480/test-app/*" rel="noreferrer" target="_blank">http://localhost:8480/test-app/*</a>&#39; --admin-url<br>
&gt; &gt; <a href="http://localhost:8480/test-app/logout" rel="noreferrer" target="_blank">http://localhost:8480/test-app/logout</a> --secret password | kc create<br>
&gt; &gt; --type default -f -<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Having to set --type for both creating a description (kc new), and<br>
&gt; &gt; pushing it to the server (kc create) is not ideal.<br>
&gt; &gt;<br>
&gt;<br>
&gt; We can detect the difference between Keycloak client rep, SAML and OIDC<br>
&gt; json that&#39;s pretty trivial and we should do that. However, there needs to<br>
&gt; be a way to specify the provider as well as there could be custom providers<br>
&gt; added.<br>
&gt;<br>
&gt; For getting the client it should by default return Keycloak client<br>
&gt; representation, but we need an option to be able to specify the provider so<br>
&gt; it can return the client installation file instead.<br>
&gt;<br>
&gt; With regards to creating by passing arguments rather than a file that<br>
&gt; should only support client representation files.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * I don&#39;t see anything in your document on how to specify the SAML<br>
&gt; &gt;&gt;&gt; metadata.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt; Instead of piping in my-client.json, you would pipe in my-client-saml.xml,<br>
&gt; &gt; possibly requiring an extra --type specifier as described above.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; * I don&#39;t see anything in your document on how the user modifies the<br>
&gt; &gt;&gt;&gt; client. It appears as if you are retrieving a ClientRepresentation JSON<br>
&gt; &gt;&gt;&gt; document and expecting the user to edit it in a text editor which will<br>
&gt; &gt;&gt;&gt; then be sent back. That won&#39;t work for non-interactive installs. It also<br>
&gt; &gt;&gt;&gt; presumes the user knows how to read and modify the JSON.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It would be nice to be able to set specific fields without having to<br>
&gt; &gt;&gt; modify JSON. We discussed that for the Admin CLI, but we should probably<br>
&gt; &gt;&gt; also add it to the client reg CLI<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
&gt; &gt; It would be very valuable to see some of the usecases, what kind of<br>
&gt; &gt; changes people do on existing clients.<br>
&gt; &gt;<br>
&gt;<br>
&gt; We should support anything that is in client representation. It should just<br>
&gt; be a generic way to change json fields. For example:<br>
&gt;<br>
&gt; # kcreg update &lt;client id&gt; --set enabled=false --set baseUrl=<br>
&gt; <a href="http://new-url/myapp" rel="noreferrer" target="_blank">http://new-url/myapp</a> --remove rootUrl<br>
&gt;<br>
&gt; This would get the KC client rep, change the corresponding fields and send<br>
&gt; it back.<br>
&gt;<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * Keycloak currently has a few problems with client registration and<br>
&gt; &gt;&gt;&gt; it&#39;s necessary to modify the client before it will work correctly. We<br>
&gt; &gt;&gt;&gt; currently do this via the REST API. How are you planning on handling<br>
&gt; &gt;&gt;&gt; these issues in your installer? It would be nice if the installer was<br>
&gt; &gt;&gt;&gt; aware of the Keycloak version and could apply &quot;fix-ups&quot; as needed based<br>
&gt; &gt;&gt;&gt; on the version.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; AFAIK you have one problem? About not all redirect URI included from the<br>
&gt; &gt;&gt; SAML entity descriptor. Is that what you are referring to or do you have<br>
&gt; &gt;&gt; other problems?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; In either case fix-ups should be performed by the client registration<br>
&gt; &gt;&gt; services, not in the CLI.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * Keycloak has two ways to register a client (client registration<br>
&gt; &gt;&gt;&gt; service vs. REST API). The two methods do not produce the same client<br>
&gt; &gt;&gt;&gt; configuration (I suspect because they do not share common code in the<br>
&gt; &gt;&gt;&gt; server). How are you planning on addressing the discrepancies?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; The task of the CLI is not to address any discrepancies. It&#39;s just<br>
&gt; &gt;&gt; invoking the client reg services. Any discrepancies should be handled by<br>
&gt; &gt;&gt; the client reg services themselves. Have you created JIRA&#39;s for these or<br>
&gt; &gt;&gt; can you list them to us?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * The tool should be smart enough to produce a working client without<br>
&gt; &gt;&gt;&gt; manual intervention (i.e. the need to run admin cli commands afterwards<br>
&gt; &gt;&gt;&gt; to fix problems). Most admins won&#39;t know how to tweak the configuration.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Can you list any you are aware of? Same comment as above applies though,<br>
&gt; &gt;&gt; it&#39;s the responsibility of the client reg services to handle this, not the<br>
&gt; &gt;&gt; CLI. Otherwise you&#39;d have different behavior if you invoke client reg<br>
&gt; &gt;&gt; services directly rather than through the CLI.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; * The tool should not have significant dependencies.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It&#39;ll be a fat-jar and will have a single dependency on the JVM.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Those are the thoughts off the top of my head, as you fill out the<br>
&gt; &gt;&gt;&gt; details I&#39;ll continue to review. Recall the plan of record is for<br>
&gt; &gt;&gt;&gt; Keycloak to provide such tools which we will then utilize. The<br>
&gt; &gt;&gt;&gt; keycloak-httpd-client-install tool is a stop-gap solution until such<br>
&gt; &gt;&gt;&gt; time as &quot;offical&quot; tools become available.<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt; John<br>
&gt; &gt;&gt;&gt; _______________________________________________<br>
&gt; &gt;&gt;&gt; keycloak-dev mailing list<br>
&gt; &gt;&gt;&gt; <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
&gt; &gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;<br>
&gt; &gt;<br>
<br>
&gt; _______________________________________________<br>
&gt; keycloak-dev mailing list<br>
&gt; <a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
&gt; <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></div></blockquote></div><br></div>