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