[keycloak-dev] Thoughts on Keycloak CLI
Stian Thorgersen
stian at redhat.com
Tue May 19 10:41:17 EDT 2015
----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 19 May, 2015 3:39:38 PM
> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI
>
> On 5/19/2015 9:27 AM, Bill Burke wrote:
> > FWIW, I agree with Stian on #2. Why wouldn't you just use the REST
> > interface in that case? IMO, JBoss CLI suffers from serious usability
> > issues. Kinda sucks we have to build on top of it.
> I agree too. #1 is better. But #2 makes it easier to "just use the
> REST interface".
Let's drop option #2 - wrapping a REST API in DMR isn't anything but a hack/work-around. Instead let's go with option #1, but with a subset for now.
> >
> > BTW, doesn't an admin password recovery scare you a little bit?
> You mean not having it is scary?
Both ;)
> > Shouldn't this be an operation that can only run in offline mode
> > directly on the machine keycloak is installed? Import/export falls into
> > this catagory too.
> Yes. I think we all agree on that.
Can we for now go for import/export + reset admin password? That get's us started on CLI support. Next step might be importing/updating clients, then managing users.
Is there a way to only allow certain operations in DMR "locally"?
Storing username/password in standalone.xml is a really horrible idea! Instead it should authenticate with username/password and store the refresh token.
> >
> > On 5/19/2015 9:05 AM, Stan Silvert wrote:
> >> On 5/19/2015 8:41 AM, Stian Thorgersen wrote:
> >>>>>> 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
> >> Indeed. That does sound like a high priority. I take it there is no
> >> existing API for that?
> >>>> * Make it easier to run import/export and allow running it offline
> >> Sounds doable.
> >>>> 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
> >>>>
> >> _______________________________________________
> >> 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