[keycloak-dev] Thoughts on Keycloak CLI

Stan Silvert ssilvert at redhat.com
Tue May 19 09:02:07 EDT 2015 

On 5/19/2015 8:41 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Stan Silvert" <ssilvert at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 19 May, 2015 2:22:26 PM
>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI
>>
>>
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 19 May, 2015 2:11:48 PM
>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI
>>>
>>> On 5/19/2015 2:22 AM, Stian Thorgersen wrote:
>>>> I'm not a big fan of Design #2, sounds like it's going to be pretty much
>>>> useless.
>>> #2 gives you an easy way to execute the REST API from the command line
>>> or via a CLI script.  Surely, that's a useful feature to have.
>> So does CURL and I bet it's easier to just use that directly than a DMR
>> wrapped REST API
Windows doesn't have curl by default.  We need something platform 
independent that integrates with the the rest of WildFly.  (Also, I 
tried doing this with curl.  It's not very easy IMO.)
>>
>>>> We should do it properly if we/when we do it. DMR/CLI is hard enough to
>>>> use
>>>> as it is!
>>> #1 is prettier.  #2 is more raw.  I don't see why we wouldn't have both
>>> eventually.  I'm halfway done with #2.  It's easy to implement and
>>> having it is better than not having it.  Plus, having #2 will make it
>>> easier to implement #1.
> Why would we have two alternatives to do the same thing?
It's possible we would get to the point where we would deprecate #2.  
But that would depend on whether or not we could auto-generate #1.  #2 
is something that would always work no matter what.  Think of #1 as 
something that puts a nicer UI on top of #2.
>
>>> Are you still thinking we should have our own proprietary CLI instead?
>> Yes, I'm pretty convinced wrapping the REST endpoint isn't going to produce
>> an usable CLI
> Can you give some examples on how this would actually look like?
I have GET requests already working:

/subsystem=keycloak-cli/:submit(method=GET,path=/demo/client-session-stats)
{
     "outcome" => "success",
     "result" => {"admin-client" => 1}
}

/subsystem=keycloak-cli/:submit(method=GET,path=/demo/roles)
{
     "outcome" => "success",
     "result" => [
         {
             "id" => "9d6cb276-3b60-4a29-bc5c-6ffb573e01d4",
             "name" => "admin",
             "description" => "Administrator privileges",
             "composite" => false,
             "composites" => undefined
         },
         {
             "id" => "7606678c-cf44-4a22-8551-549136047a9c",
             "name" => "user",
             "description" => "User privileges",
             "composite" => false,
             "composites" => undefined
         }
     ]
}
> Also, how is authentication done?

Authentication is done the same way as in the AdminClient.java example.  
Username and password can be stored in standalone.xml or passed along 
with each request.  We could cache the AccessToken so you only have to 
specify it once.

If you are using Keycloak to authenticate CLI then it's also possible to 
use the AccessToken you got when you logged into CLI.



>
>>>> 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
>> * Make it easier to run import/export and allow running it offline
>>
>> 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
>>

More information about the keycloak-dev mailing list