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