[keycloak-dev] Client Registration CLI tool

[Marko Strukelj]

On Tue, Jun 28, 2016 at 11:40 AM, Marko Strukelj <mstrukel at redhat.com>
wrote:

>
>
> On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On 27 June 2016 at 21:26, John Dennis <jdennis at redhat.com> wrote:
>>
>>> On 06/27/2016 07:48 AM, Marko Strukelj wrote:
>>> > I've started work on Client Registration CLI tool. As a first step,
>>> here
>>> > is a design document describing how I imagine the tool would be used.
>>> >
>>> >
>>> >
>>> https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk5dpIhU/edit?usp=sharing
>>> >
>>> >
>>> > I'll use this document as a spec / guide as I implement the client
>>> tool.
>>> >
>>> > Within days I'll also send a link to initial ideas for Admin Client
>>> tool
>>> > which in principle should allow administrator to configure everything
>>> > that can otherwise be done through Admin Console.
>>> >
>>> > Any feedback welcome.
>>>
>>> FWIW we've already written a client registration tool for Keycloak. At
>>> the moment it is specifically targeted for SAML clients (SP, Service
>>> Provider) in Apache HTTPD but we have plans to extend it to OIDC.
>>>
>>> It is currently in Fedora and will also ship in OSP.
>>>
>>> It is hosted here:
>>> https://github.com/jdennis/keycloak-httpd-client-install
>>>
>>> The man page for it (formatted for HTML) can be found here:
>>> https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
>>>
>>> The man page discusses 3 different ways you can authenticate and 2
>>> different ways client registration can be performed.
>>>
>>> I have a lot of experience with Keycloak client registration tools and
>>> have worked through many issues, I'm happy to share my experience.
>>>
>>> Here are some thoughts/issues you may want to take into account:
>>>
>>> * The tool must be capable of running without interactivity as part of a
>>> scripted installation task.
>>>
>>> * It should not depend on a home directory being available.
>>>
>>> * If a home directory is utilized how will you disambiguate any stored
>>> state belonging to a script that is run by different processes but under
>>> the same user (possibly simultaneously)? To clarify, many install tools
>>> run as the root user or some other admin user. Each invocation of these
>>> install tools can be run with entirely different parameters and may
>>> execute either in parallel or partially overlapping in time.
>>>
>>
> Maybe I should have included this link in the design document to make it
> clear to everyone what Client Registration this tool is for:
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html
>
> It's a REST API defined by specs, and is separate from Admin REST API.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
Thinking a bit more about this, I think OpenShift Client solves this
problem by allowing you to specify a path to .kubeconfig file (via
--credentials or --config argument) which I believe serves the same purpose
as the proposed kc.cache file.

So by adding something like --config PATH or --credentials PATH or --cachefile
PATH you can use a random file path for each 'session', and thus achieve
clear separation.

For example:

$ kc login -s http://localhost:8080/auth -r $REALM -u $USER -p
$PASSWORD --config
/tmp/.kc_$SESSION.cfg

$ kc create --config /tmp/.kc_$SESSION.cfg -f /tmp/.kc_client_$SESSION.json
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160628/fff5f5a4/attachment.html