[keycloak-dev] Thoughts on Keycloak CLI

[Stian Thorgersen]

I'm not a big fan of Design #2, sounds like it's going to be pretty much useless. We should do it properly if we/when we do it. DMR/CLI is hard enough to use as it is!

The first priority for CLI is to have support to reset admin password and to do import/export, not the admin endpoints. We also need to make sure we can authenticate properly using Keycloak.

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