[keycloak-dev] Feedback on Client Registration CLI

[Bruno Oliveira]

On 2016-07-22, Marko Strukelj wrote:
> On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > A few questions from me:
> >
> > * Is it possible to view the returned JSON when creating and updating a
> > client? This contains values filled in by the server, including the
> > registration access token.
> >
> Not ATM. I can add an option e.g.  -o, --output     Display the new state
> of client configuration.
>
>
> > * Should we not enable pretty print by default?
> >
> I suppose that would be more user friendly. Just don't know how to name the
> switch -p, --pretty is so obvious ...

Some command line interfaces use --format.

>
>
> > * --cache isn't the most intuitive name, I don't have a better suggestion
> > though
> >
> OpenShift client uses the term configuration rather than cache, and uses
> --config accordingly. We could do the same, and even add 'kcreg config'
> command to inspect and edit the config file if we deem that necessary.
>
> * Docs should be moved to Gitbook "Securing Clients and Applications guide"
> >
> The only doc currently is the README file, so I guess that's the one you
> mean. I'd wait a bit with adding it to docbook. The later I make a copy in
> Gitbook the less double work will there be editing the changes.
>
>
> > * When creating clients and later updating them I assume it uses the
> > registration access token from the cache?
> >
> Yes. If it can't find one it uses bearer token from login.
>
>
> > * A nice addition would be the ability to list attributes from
> > ClientRepresentation so it's easy to discover what attributes can be set
> >
> That's trivial to add using reflection. But how would the UI look? Ideally
> we'd have tab completion for this at some point.
>
> Something like this?
>
> $ kcreg list-attrs
> clientId            String
> redirectUris     List<String>
> baseUrl           String
> enabled           Boolean
> ...
>
> $ kcreg list-attrs -e oidc
> redirect_uris    List<String>
> grant_types     List<String>
>
>
> However if we want to be more specific, with some additional help on the
> meaning, and possible values, then we would need to annotate Representation
> classes with the necessary info, or simply have a help-style static text.
>
>
>
> > * What about setting/changing complex attributes, how does that look like?
> > Can we add/remove to an array? Add/remove elements to a complex object?
> > Something like JSON patch could be nice
> > https://tools.ietf.org/html/rfc6902
> >
> I haven't gone so far with this iteration. That's a TODO.
>
>
> >
> > On 22 July 2016 at 09:26, Stian Thorgersen <sthorger at redhat.com> wrote:
> >
> >> It should be fairly easy to add support for OTP as well as the direct
> >> grant supports that. The user would have to specify to use OTP though.
> >>
> >> On 21 July 2016 at 19:15, 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.
> >>>
> >>> 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?
> >>>
> >>>
> >>> 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