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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Looks good. Are we going to have similar CLI efforts to manage other parts of the server? On 7/21/16 10:47 AM, Marko Strukelj wrote: And if anyone wants to get their feet wet already: https://github.com/mstruk/keycloak/tree/cli-reg/integration/client-regist... On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ keycloak-dev mailing listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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-regist... > > > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)redhat.com&gt; > 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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj PGP: 0x84DC9914

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. * Should we not enable pretty print by default? * --cache isn't the most intuitive name, I don't have a better suggestion though * Docs should be moved to Gitbook "Securing Clients and Applications guide" * When creating clients and later updating them I assume it uses the registration access token from the cache? * A nice addition would be the ability to list attributes from ClientRepresentation so it's easy to discover what attributes can be set * 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 On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)abstractj.org&gt; 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-regist... >> > >> > >> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen <sthorger(a)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(a)lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > >

I don't have kcreg.bat yet ... contributions welcome :) Making it part of keycloak server distro makes sense. OTOH I believe we have some developers that just deal with HTML5 web apps who don't have Keycloak Server installed locally. If that was the only way to get kcreg they would have to download the whole server just to get the tool. For them it makes sense to also have a separate CLI Tools download. On Fri, Jul 22, 2016 at 9:40 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > One more: > > * How should we distribute it? I propose we just add kcreg.sh/kcreg.bat > + the JAR to the bin directory of the server > > On 22 July 2016 at 09:33, Stian Thorgersen <sthorger(a)redhat.com&gt; 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. >> * Should we not enable pretty print by default? >> * --cache isn't the most intuitive name, I don't have a better >> suggestion though >> * Docs should be moved to Gitbook "Securing Clients and Applications >> guide" >> * When creating clients and later updating them I assume it uses the >> registration access token from the cache? >> * A nice addition would be the ability to list attributes from >> ClientRepresentation so it's easy to discover what attributes can be set >> * 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 >> >> On 22 July 2016 at 09:26, Stian Thorgersen <sthorger(a)redhat.com&gt; 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(a)abstractj.org&gt; 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-regist... >>>> > >>>> > >>>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < >>>> sthorger(a)redhat.com&gt; >>>> > 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(a)lists.jboss.org >>>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> > > >>>> >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev(a)lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> >>> >>> >> >

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.

* Should we not enable pretty print by default?

* --cache isn't the most intuitive name, I don't have a better suggestion though

On 2016-07-22, Marko Strukelj wrote: > On Fri, Jul 22, 2016 at 9:33 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)abstractj.org&gt; 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-regist... > >>> > > >>> > > >>> > On Thu, Jul 21, 2016 at 4:06 PM, Stian Thorgersen < sthorger(a)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(a)lists.jboss.org > >>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > > > >>> > >>> > _______________________________________________ > >>> > keycloak-dev mailing list > >>> > keycloak-dev(a)lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> > >> > >> > > -- abstractj PGP: 0x84DC9914

Nice work Marko!

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

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?