[keycloak-dev] Feedback on Client Registration CLI

[Stian Thorgersen]

On 22 July 2016 at 12:02, Marko Strukelj <mstrukel at redhat.com> 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.
>

Please do


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

-u --ugly ;)

or a more serious suggestion

-c --compressed


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

+1 --config is better - config would be nice as well


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

Sure, just remember to do it before moving on to Admin CLI


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

That's fine and you only need it for our representation. I wouldn't use
Java names for types though, rather use JSON names


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

Ok, would nice to visit before we start on Admin CLI as it would be
incredibly useful there.


>
>
>>
>> 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
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160722/040fe057/attachment.html