[keycloak-dev] Thoughts on Keycloak CLI

Stian Thorgersen stian at redhat.com
Tue May 19 08:41:26 EDT 2015 


----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 19 May, 2015 2:22:26 PM
> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI
> 
> 
> 
> ----- Original Message -----
> > From: "Stan Silvert" <ssilvert at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 19 May, 2015 2:11:48 PM
> > Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI
> > 
> > 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.
> 
> So does CURL and I bet it's easier to just use that directly than a DMR
> wrapped REST API
> 
> > > 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.

Why would we have two alternatives to do the same thing?

> > 
> > Are you still thinking we should have our own proprietary CLI instead?
> 
> Yes, I'm pretty convinced wrapping the REST endpoint isn't going to produce
> an usable CLI

Can you give some examples on how this would actually look like? Also, how is authentication done?

> 
> > >
> > > 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?
> 
> Adding operations from admin endpoints (create/update realm, create/update
> users, etc.) isn't the highest priority. What we do need is:
> 
> * Recover admin password - if a user looses the admin password there's no
> easy way to recover access other than manually editing the database
> * Make it easier to run import/export and allow running it offline
> 
> As we're using JBoss CLI, which now has an offline mode, that's the perfect
> place to add those operations.
> 
> > >
> > > ----- 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
> > 
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

More information about the keycloak-dev mailing list