Was just talking to AOS team. Seems that it will fit real nicely as
kubernetes has an SPI for plugging in tools like this:
On Mon, Mar 12, 2018 at 3:36 PM, Pedro Igor Silva <psilva(a)redhat.com> wrote:
Another thing you might consider is talk with Peter about how you can
use
Elytron to secure tokens using a credential store. Elytron is a very tinny
library and there is an API for managing/storing credentials in a secure
manner.
If you are not going to move everything to Go ....
On Mon, Mar 12, 2018 at 4:15 PM, Bill Burke <bburke(a)redhat.com> wrote:
>
> The "resource owner password credentials" grant type isn't really
> implemented as a multi-request flow and would have taken a bit of
> refactoring work.
>
> On Mon, Mar 12, 2018 at 2:36 PM, Pedro Igor Silva <psilva(a)redhat.com>
> wrote:
> > 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(a)redhat.com> wrote:
> >>
> >> On Mon, Mar 12, 2018 at 10:16 AM, Stian Thorgersen
> >> <sthorger(a)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(a)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(a)lists.jboss.org
> >> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat