[keycloak-dev] Thoughts on Keycloak CLI

[Bill Burke]

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.

BTW, doesn't an admin password recovery scare you a little bit? 
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.

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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com