[keycloak-dev] Thoughts on Keycloak CLI

[Stan Silvert]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150518/1dd75449/attachment.html