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