[keycloak-dev] Thoughts on Keycloak CLI

[Stan Silvert]

On 5/19/2015 2:22 AM, Stian Thorgersen wrote:
> I'm not a big fan of Design #2, sounds like it's going to be pretty much useless.
#2 gives you an easy way to execute the REST API from the command line 
or via a CLI script.  Surely, that's a useful feature to have.
> We should do it properly if we/when we do it. DMR/CLI is hard enough to use as it is!
#1 is prettier.  #2 is more raw.  I don't see why we wouldn't have both 
eventually.  I'm halfway done with #2.  It's easy to implement and 
having it is better than not having it.  Plus, having #2 will make it 
easier to implement #1.

Are you still thinking we should have our own proprietary CLI instead?
>
> 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?
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at 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 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