----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: keycloak-dev(a)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(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
>>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev