On Thu, Jul 21, 2016 at 7:15 PM, Bruno Oliveira <bruno@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@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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >

> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


--

abstractj
PGP: 0x84DC9914