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(a)redhat.com>
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