Re: [keycloak-dev] Thoughts on Keycloak CLI

>>> The first priority for CLI is to have support to reset admin password and >>> to do import/export, not the admin endpoints. >> Is reset admin password not allowed from the REST API? >>> We also need to make sure we can authenticate properly using Keycloak. >> I'm not sure what you mean by this. Can you elaborate? > Adding operations from admin endpoints (create/update realm, create/update > users, etc.) isn't the highest priority. What we do need is: > > * Recover admin password - if a user looses the admin password there's no > easy way to recover access other than manually editing the database

> * Make it easier to run import/export and allow running it offline

> > As we're using JBoss CLI, which now has an offline mode, that's the perfect > place to add those operations.

> >>> ----- Original Message ----- >>>> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>> To: keycloak-dev(a)lists.jboss.org >>>> Sent: Monday, 18 May, 2015 8:38:40 PM >>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >>>> >>>> BTW, I've got some down time waiting on Elytron, so I've decided to do a >>>> quickie implementation of #2 to see how it goes. >>>> >>>> On 5/15/2015 8:36 AM, Stan Silvert wrote: >>>> >>>> >>>> I've been giving some thought to the Keycloak integration with WildFly >>>> CLI. >>>> There are two designs. Both involve a subsystem called "kcrest" with a >>>> resource called "server". You can define a server to talk to using these >>>> three attributes: >>>> base-url ( value is something like >>>> http://localhost:8080/auth/admin/realms >>>> ) >>>> username >>>> password >>>> >>>> username and password are optional. If you don't mind having these >>>> values >>>> stored in standalone.xml/domain.xml you can specify them. That way, you >>>> don't have to include them with each request. >>>> >>>> Design #1: Implement all of the Keycloak REST API in CLI >>>> We build out resources for each REST path and put them in the management >>>> model. Then build out operations for everything. So a CLI session to >>>> create >>>> a client called "myclient" might look like this: >>>> cd /subsystem=kcrest/server=foo >>>> cd realm=myrealm >>>> clients=myclient:add(enabled=true) >>>> >>>> Design #2: Create a single generic operation that closely mimics the >>>> REST >>>> API >>>> cd /subsystem=kcrest/server=foo >>>> :submit(method=POST, >>>> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) >>>> >>>> Advantages of Design #1 >>>> >>>> >>>> * Looks and behaves just like other CLI resources >>>> * Uses standard CLI operations >>>> * Each resource and operation can contain help text >>>> * Everything can be navigated from CLI command line or CLI GUI >>>> tree, >>>> making it easy to browse the model >>>> >>>> >>>> Disadvantages of Design #1 >>>> >>>> >>>> * It might take a very long time to implement (2-3 months?) >>>> * Ongoing maintenance. Every time REST API changes, you have to >>>> update >>>> subsystem code >>>> >>>> >>>> Advantages of Design #2 >>>> >>>> >>>> * Quick to implement (2-3 weeks) >>>> * Always works despite REST API changes >>>> >>>> >>>> Disadvantages of Design #2 >>>> >>>> >>>> * :submit operations get long and ugly >>>> * Can't specify help text for each resource >>>> * Hard to browse the model. Need to submit "list" style REST >>>> invocations. >>>> >>>> >>>> Note that it might be possible to auto-generate Design #1. If so, it >>>> would >>>> be >>>> the best of both worlds. >>>> >>>> >>>> Whoever implements this should probably start with Design #2 and then >>>> spend >>>> some time researching auto-generation of Design #1. >>>> >>>> >>>> Other thoughts? >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >