[keycloak-dev] Feedback on Client Registration CLI

[Marko Strukelj]

On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Nice work Marko!

I had two (not big deal) questions. First, when you
> specify the --cache parameters as you did for SAML, could the cache file
> be omitted?
>
> For example: kcreg --cache -r saml-realm ...
>
> I was thinking that once you specified the realm name, the API will just
> look for ~/.keycloak/saml-realm.cache. It's just an idea


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:

    # login as admin user in master realm on localhost using default cache
file (~/.keycloak/kcreg.cache)
    kcreg login -s http://localhost:8080/auth -r master -u admin

    # login as admin user in master realm on login.example.com using a
different cache file
    kcreg --cache ~/.keycloak/example_com.cache login -s
http://login.example.com -r master -u admin


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.

The current mechanism reads the server from the specified cache file (the
server for current session it's stored inside a JSON):

    kcreg --cache ~/.keycloak/localhost_8080_auth_master.cache get my_client


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:

    kcreg --cache -r master get my_client

The above can resolve to ~/.keycloak/master.cache but doesn't have enough
info to resolve to ~/.keycloak/localhost_8080_auth_master.cache.

If we also have to specify server the result is not worth the bother:

    kcreg --cache -s http://localhost:8080/auth -r master get my_client


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:

kcreg --cache login -r master ...

vs.

kcreg --cache /tmp/session.cache -x login ...

vs.

kcreg --cache -r master get ...


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 ...

The more I look at it, the more complex and tricky it gets to get it right.


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.

For example:

kcreg --cache master login -s http://localhost:8080/auth -r master -u admin

This would generate the following cache file: ~/.keycloak/master.cache, and
the folling command would use that file as well:

kcreg --cache master get my_client


The absolute names would be those starting with /, ~/ on unix, c:\, d:\ ...
on Windows

This behaviour is easy to add.


>
>
Second question, is more like something to think if worth to take
> into consideration. Most of the examples that I saw, make use of
> username/password. But if the admin enables two factor authentication,
> she might be unable to use our client-reg CLI, or enforce weaken security
> only
> to make use of the CLI.
>
> Is OTP support planned for further iterations?


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 :)


>


> On 2016-07-21, Marko Strukelj wrote:
> > And if anyone wants to get their feet wet already:
> >
> >
> https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-registration-cli-tool
> >
> >
> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> > > Great work Marko!
> > >
> > > As we didn't have time to go through feedback let's use this thread for
> > > it. Add your questions and comments here please.
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/1d42005f/attachment.html