[keycloak-dev] kcinit console sso tool

[Pedro Igor Silva]

Bill, I'm curious about why you are not using resource owner password
credentials grant type. Wouldn't be simpler instead of using authorization
code ?

On Mon, Mar 12, 2018 at 2:59 PM, 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).
>
> BTW, what sucks about a browser login is that you have to manually
> kill the browser window after you complete the login.
>
> > * Not sure I fully understand the user experience with the encrypted
> > password file. How does this compare to kinit and ssh-agent for instance?
> > They both allow unlocking automatically through the regular OS login I
> > believe. For 'kcadmin' and 'kcclient' we don't currently protect the
> tokens
> > so we should probably consider aligning these approaches (probably even
> > getting rid of the auth stuff there in favour of kcinit).
> >
>
> I just read up on kinit and ssh-agent.  Have you actually used either
> of these before(I haven't)?  I don't think they work as you think they
> do.
>
> For instance, ssh-agent is a bit convoluted and requires IPC
> communication with a background process using a file-based socket.
> The background process holds private keys in memory which must be
> unlocked and loaded with a password when you boot your windows manager
> or your shell.  The socket used must be set as an environment variable
> before you can invoke ssh in your shell.  I think when you invoke ssh,
> it looks for this environment variable and works with the ssh-agent to
> establish a connection over the local file socket.
>
> For kinit, I think to have a global login for the entire machine, it
> creates a keytab file which has file permissions readable by any
> process started by the user.  And the keytab contains the tickets.
> This is no different than what we do now for kcadmin.
>
> The current solution I have is only for creating an sso session for
> the current shell and any processes run within the shell would be able
> to figure out how to access the encrypted token files.
>
>
> > * Should we consider merging all our CLIs into one CLI? Just 'kc'
> instead of
> > 'kcinit', 'kcadmin' and 'kcclient'? If we someone could get this stuff
> in Go
> > and get native binaries that'd be even easier for users to use.
> >
>
> kcadmin and kcclient should be merged.  kcinit should be a separate
> small generic reusable utility.
>
>
> > On 12 March 2018 at 14:29, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> I'm finally finishing the generic console login tool I've been
> >> promising and working on for awhile now.  Its an extension of
> >> KeycloakInstalled, but it works entirely on the command line and
> >> doesn't require a browser.  Its all text input and output in your
> >> command line console to login.  All driven by the server and rendered
> >> by the utility.   Supports localization just like the browser too.
> >>
> >> * To enable this a simple challenge-based protocol was implemented.
> >> OAuth Code to token flow is required.
> >>
> >>  Authenticator returns 401 with a WWW-Authenticate header with value of
> >>
> >> X-Text-Form-Challenge callback="{url}" param="username"
> >> label="Username: " mask="false"
> >>
> >> param/label/mask are input parameter definitions that require command
> >> line console input and can be repeated for each input parameter you
> >> require from the console.  Label is what should be outputed to the
> >> console.  If mask is true, this means it is a password field and
> >> should be hidden on input.
> >>
> >> If the Response contains "text/plain" content, then that should be
> >> outputed before command input is asked for.  Client should loop and
> >> render/ask for input until a 302 response is returned that contains a
> >> "code" parameter.  Then regular OAuth is used to get the token.
> >>
> >> * The access and refresh token is stored locally in a password
> >> protected file (like ssh does). This file is checked before login is
> >> initiated to see if the user is still logged in.
> >>
> >> * If logged in, and the client has permission, the kcinit tool can
> >> also perform token exchange to obtain tokens for other clients.  It
> >> stores these tokens in password protected files on local disk.
> >>
> >> * I have extended the OAuth layer on the server to support the OIDC
> >> "display" parameter. (It just stores this value in the AuthSession.
> >> I'm also in the process to refactor all the built-in Authenticators
> >> and Required Actions to support the "display" parameter and use the
> >> texts protocol described above if the "display" parameter is
> >> "console".
> >>
> >> * kcinit is implemented via Java and a shell and windows batch
> >> scripts.  There's also a wrapper template script that can be used to
> >> secure existing command line tools.  here's example usage with the
> >> target app command being `oc`.
> >>
> >> $ . kcinit
> >>
> >> Initially you will be prompted for the "local password" that protects
> >> token files on local disk.  If you do not "source" this script (with a
> >> '.' or 'source' command), then you will have to enter in this local
> >> password every time you interact with kcinit utility.
> >>
> >> the kcinit script will prompt for this local password.  Once it gets
> >> the password value, it will invoke the Java kcinit program:
> >>
> >> read -sp 'Local password: ' password
> >> KC_SESSION_KEY=`java -jar kcinit.jar password $password`
> >>
> >> The `password` command will generate an AES key from the password that
> >> will be used encrypt and decrypt locally stored files.  I do it this
> >> way so that when the user's shell is exited, they can no longer access
> >> stored tokens.
> >>
> >> Once the user is logged in, they can start using command line
> >> utilities that are secured by it.  To secure a command line utility
> >> the developer must use a wrapper script for each of their command line
> >> tools.  The wrapper script looks like this
> >>
> >> - checks to see if KC_SESSION_KEY is set.  If not, it will prompt for
> >> the local password and generate this key.
> >> - It then tries to obtain the token for the app
> >>
> >> token=`java -jar kcinit.jar token oc`
> >>
> >> This will perform a token exchange to obtain a token for the `oc`
> >> client.  If this is not successful, an error message is displayed
> >> (i.e. "You are not logged in".)  If successful, then the target
> >> command line tool is invoked.  The tool extracts the "token"
> >> environment variable to invoke on its REST services.
> >>
> >> $path_to_real_command/$0 $@
> >>
> >> * There is an install option for kcinit
> >>
> >> $ kcinit install
> >>
> >> This will prompt you for auth server url, realm, client, client
> >> secret, and the local password to encrypt things.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>