[keycloak-dev] kcinit console sso tool

[Stian Thorgersen]

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
>