[keycloak-dev] Thoughts on Keycloak CLI

[Stan Silvert]

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