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".
BTW, doesn't an admin password recovery scare you a little bit?
You mean not
having it is scary?
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.
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
>