[keycloak-dev] Feedback on Client Registration CLI

[Bruno Oliveira]

If changing the interface is going to be tricky, just ignore my idea. I haven't
played with it yet, so any suggestion will be really inaccurate :)

On 2016-07-22, Marko Strukelj wrote:
> 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
> >

--

abstractj
PGP: 0x84DC9914