[keycloak-dev] kcinit console sso tool

Bill Burke bburke at redhat.com
Tue Mar 20 17:10:32 EDT 2018


FYI,  I reimplemented this command line tool in Golang.  I'll be
putting together a screencast to show it in action.

https://github.com/keycloak/kcinit

I also integrated a maven golang plugin so that Java based tests in
the arquillian testsuite can run and test it.  I need to send a
separate email about that.

BTW, this tool fits in real nice with openshift and kubernetes
integration.  Needed a way for `oc` and `kubectl` to obtain a keycloak
token and kcinit is it.


On Fri, Mar 16, 2018 at 3:48 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On 15 March 2018 at 15:41, Bill Burke <bburke at redhat.com> wrote:
>>
>> On Wed, Mar 14, 2018 at 3:15 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> >
>> >
>> > On 12 March 2018 at 18:59, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen
>> >> <sthorger at redhat.com>
>> >> wrote:
>> >> > Very cool. A few questions/comments:
>> >> >
>> >> > * As it's Java based it does make it harder to package/install.
>> >> > Compare
>> >> > 'oc'
>> >> > tool for instance to our 'kcadmin' and 'kcclient' tools. Not sure how
>> >> > realistic it would be to write our CLI tools in for instance Go
>> >> > though.
>> >> >
>> >>
>> >> Its a pretty simple tool so it could be ported.  The only thing that
>> >> might be a tiny bit challenging is making sure there's crypto stuff
>> >> available in another language to encrypt/decrypt token files.  Might
>> >> be a nice little project for me to learn Go.
>> >>
>> >> > * I assume the console display is optional and it basically means
>> >> > that
>> >> > you
>> >> > can only use authenticators that support this rather than all
>> >> > authenticators
>> >> > require to implement it.
>> >> >
>> >>
>> >> I don't have a switch to launch browser, but, I could as this
>> >> functionality is already implemented.  Not sure if that would be
>> >> portable to Go or another language though.  Java has a facility to
>> >> automatically launch browser (I think you know that already as you
>> >> wrote KeycloakInstalled).
>> >
>> >
>> > That would be pretty cool, but I wasn't thinking that far. I was just
>> > basically thinking that authenticators has to be written to support
>> > this,
>> > rather than all authenticators have to support this.
>>
>> Pretty cool?  LOL!  You implemented the browser stuff!
>
>
> What I meant was if there was some fallback where the browser would be
> opened to continue the flow in case there is an authenticator that doesn't
> have this, but as you say since you can't close the window automatically
> it's kinda awkward.
>
>>
>>
>> Its not a requirement to support this when writing an authenticator.
>>
>>
>> >
>> > I got no clue how they work, but what I meant is the fact that ssh-agent
>> > allows you to unlock the keys automatically when you login to your
>> > browser.
>> >
>> > If you have to provide a password to unlock the tokens every time you
>> > open a
>> > new shell does it actually provide a nicer experience than just doing
>> > username/password to login again with resource owner credential grant?
>> >
>>
>> I agree it sucks.  I think I'm going to get rid of password protection
>> for now.   I researched things a bit last night, and at least for
>> Golang, there is a cross-platform library for storing passwords in the
>> OS's keyring that might be useful.
>>
>> https://github.com/zalando/go-keyring
>>
>> I'll look into that when I port this tool to Go.
>>
>> --
>> Bill Burke
>> Red Hat
>
>



-- 
Bill Burke
Red Hat


More information about the keycloak-dev mailing list