Sorry about the duplicated e-mail.
On Wed, Jun 29, 2016, 11:21 PM Stian Thorgersen <sthorger(a)redhat.com> wrote:
On 30 June 2016 at 08:08, Bruno Oliveira <bruno(a)abstractj.org>
wrote:
> What I suggested was based on what I saw at our current proposal:
>
> $ kcreg login -r master -u manage-client
> Server to connect to (
http://localhost:8080/auth):
> Password:
>
> If you want to automate it for example in a shell script, unless I'm
> mistaken, you have to provide user's password or obtain initial access
> token through console. If we're assuming that's the default
> flow for automated scripts should be obtaining an initial access token
> from console first, that's fine.
>
Yes, the password is just for manual use and wouldn't be cached or
anything like that.
>
> Flow for encryption:
>
> 1. Admin client retrieve the public key from the server
> 2. Admin client encrypt's whatever data is sensitive
> 3. Server decrypt's it
>
Isn't that only going to hide the password? The encrypted password could
still be used as the server would accept/decrypt it.
Not only passwords, but username as well. Into other words any sensitive
data.
I don't follow you on this. The server will decrypt and validate those
credentials.
Anyways, this is just an idea, if it doesn't worth it, never mind.
>
> On 2016-06-30, Stian Thorgersen wrote:
> > I can't see why we should consider it though:
> >
> > a) We have service account support, initial access tokens, offline
> tokens,
> > etc.. All designed so credentials don't need to be stored. Using a user
> > account directly is horrible as not only are you potentially exposing
> the
> > credentials, you're also giving all permissions of the user to the
> > automation. Using tokens or service account you can limit what
> permissions
> > the automation has.
> > b) If the credentials are encrypted, you'll also need to unlock the
> > vault/encrypted file. How would you suggest we do that? I can't see the
> > full flow here.
> >
> > On 30 June 2016 at 07:15, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> >
> > > Yes, the encrypted data goes into public repository with .travis.yaml
> file.
> > > Only the Travis server is able to decrypt such data and validate
> it[1][2].
> > >
> > > Like I mentioned, not a blocker, but maybe something to take into
> > > consideration.
> > >
> > > [1] -
> > >
>
https://docs.travis-ci.com/user/encryption-keys/#Notifications-Example
> > > [2] -
>
https://github.com/twbs/bootstrap/blob/master/.travis.yml#L30-L32
> > >
> > > On 2016-06-30, Stian Thorgersen wrote:
> > > > The encryption support in Travis isn't that so you can encrypt
> sensitive
> > > > details that goes into .travis.yaml which is public through the
> repo?
> > > >
> > > > On 30 June 2016 at 06:52, Stian Thorgersen
<sthorger(a)redhat.com>
> wrote:
> > > >
> > > > > I don't see the need for that. For the client registration
CLI we
> will
> > > > > support initial access tokens as well as service accounts with
> > > pub/priv key
> > > > > authentication. For admin cli we'll support service accounts.
No
> one
> > > should
> > > > > be using username/password combined with automated jobs.
> > > > >
> > > > > On 29 June 2016 at 21:49, Bruno Oliveira
<bruno(a)abstractj.org>
> wrote:
> > > > >
> > > > >> I'm not sure if it's part of the scope for now. But
> > > > >> thinking about situations where you have to automate jobs
plus
> provide
> > > > >> credentials without exposing them.
> > > > >>
> > > > >> My suggestion, even if it's not part of the scope for now
is to
> > > encrypt
> > > > >> it,
> > > > >> like travis does[1]. I know that our plan is to deal of
access
> token,
> > > > >> but would be nice to not expose credentials not even a
single
> time.
> > > > >>
> > > > >>
> > > > >> [1] -
https://docs.travis-ci.com/user/encryption-keys/
> > > > >>
> > > > >> On 2016-06-29, Stian Thorgersen wrote:
> > > > >> > On 28 June 2016 at 11:40, Marko Strukelj
<mstrukel(a)redhat.com>
> > > wrote:
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Tue, Jun 28, 2016 at 7:35 AM, Stian Thorgersen
<
> > > > >> sthorger(a)redhat.com>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> On 27 June 2016 at 21:26, John Dennis
<jdennis(a)redhat.com>
> > > wrote:
> > > > >> > >>
> > > > >> > >>> On 06/27/2016 07:48 AM, Marko Strukelj
wrote:
> > > > >> > >>> > I've started work on Client
Registration CLI tool. As a
> first
> > > > >> step,
> > > > >> > >>> here
> > > > >> > >>> > is a design document describing how I
imagine the tool
> would
> > > be
> > > > >> used.
> > > > >> > >>> >
> > > > >> > >>> >
> > > > >> > >>> >
> > > > >> > >>>
> > > > >>
> > >
>
https://docs.google.com/document/d/18SoZ34sY_k7N8ae-WDsvo7QeI-cHkpTURIlUk...
> > > > >> > >>> >
> > > > >> > >>> >
> > > > >> > >>> > I'll use this document as a spec /
guide as I implement
> the
> > > client
> > > > >> > >>> tool.
> > > > >> > >>> >
> > > > >> > >>> > Within days I'll also send a link
to initial ideas for
> Admin
> > > > >> Client
> > > > >> > >>> tool
> > > > >> > >>> > which in principle should allow
administrator to
> configure
> > > > >> everything
> > > > >> > >>> > that can otherwise be done through
Admin Console.
> > > > >> > >>> >
> > > > >> > >>> > Any feedback welcome.
> > > > >> > >>>
> > > > >> > >>> FWIW we've already written a client
registration tool for
> > > Keycloak.
> > > > >> At
> > > > >> > >>> the moment it is specifically targeted for
SAML clients
> (SP,
> > > Service
> > > > >> > >>> Provider) in Apache HTTPD but we have plans
to extend it to
> > > OIDC.
> > > > >> > >>>
> > > > >> > >>> It is currently in Fedora and will also
ship in OSP.
> > > > >> > >>>
> > > > >> > >>> It is hosted here:
> > > > >> > >>>
https://github.com/jdennis/keycloak-httpd-client-install
> > > > >> > >>>
> > > > >> > >>> The man page for it (formatted for HTML)
can be found here:
> > > > >> > >>>
> > > > >>
> > >
>
https://jdennis.fedorapeople.org/doc/keycloak-httpd-client-install.html
> > > > >> > >>>
> > > > >> > >>> The man page discusses 3 different ways you
can
> authenticate
> > > and 2
> > > > >> > >>> different ways client registration can be
performed.
> > > > >> > >>>
> > > > >> > >>> I have a lot of experience with Keycloak
client
> registration
> > > tools
> > > > >> and
> > > > >> > >>> have worked through many issues, I'm
happy to share my
> > > experience.
> > > > >> > >>>
> > > > >> > >>> Here are some thoughts/issues you may want
to take into
> account:
> > > > >> > >>>
> > > > >> > >>> * The tool must be capable of running
without
> interactivity as
> > > part
> > > > >> of a
> > > > >> > >>> scripted installation task.
> > > > >> > >>>
> > > > >> > >>> * It should not depend on a home directory
being available.
> > > > >> > >>>
> > > > >> > >>> * If a home directory is utilized how will
you
> disambiguate any
> > > > >> stored
> > > > >> > >>> state belonging to a script that is run by
different
> processes
> > > but
> > > > >> under
> > > > >> > >>> the same user (possibly simultaneously)? To
clarify, many
> > > install
> > > > >> tools
> > > > >> > >>> run as the root user or some other admin
user. Each
> invocation
> > > of
> > > > >> these
> > > > >> > >>> install tools can be run with entirely
different
> parameters and
> > > may
> > > > >> > >>> execute either in parallel or partially
overlapping in
> time.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > > Maybe I should have included this link in the
design
> document to
> > > make
> > > > >> it
> > > > >> > > clear to everyone what Client Registration this
tool is for:
> > > > >> > >
> > > > >>
> > >
>
http://keycloak.github.io/docs/userguide/keycloak-server/html/client-regi...
> > > > >> > >
> > > > >> > > It's a REST API defined by specs, and is
separate from Admin
> REST
> > > API.
> > > > >> > >
> > > > >> > > About using home directory, the way I see it - you
either a)
> > > specify
> > > > >> all
> > > > >> > > the state when executing a command, or b) you have
a
> mechanism
> > > that
> > > > >> allows
> > > > >> > > the concept of 'session' between command
invocations.
> > > > >> > >
> > > > >> > > If you use the first approach (a) then on each
invocation of
> the
> > > > >> command
> > > > >> > > you have to specify either username:password, or a
token. The
> > > client
> > > > >> > > registration specification defines workflow for
Initial
> Access
> > > > >> Tokens, and
> > > > >> > > Registration Access Tokens, which require to
automatically
> > > intercept a
> > > > >> > > newly issued token after each CRUD operation, and
save it
> for any
> > > > >> > > subsequent operation on the same client resource. I
can't
> see how
> > > this
> > > > >> > > could be achieved by using the first approach.
> > > > >> > >
> > > > >> > > For the second approach (b) you need a way to
communicate
> > > 'session'
> > > > >> state.
> > > > >> > > The state we are saving are just tokens associated
with
> current
> > > user
> > > > >> or
> > > > >> > > specific clients, or specific grants. Looks to me
that if
> multiple
> > > > >> parallel
> > > > >> > > sessions are in collision about these tokens then
the cli
> tool
> > > itself
> > > > >> might
> > > > >> > > be used the wrong way. Namely, once the client
authenticates
> with
> > > a
> > > > >> login,
> > > > >> > > access token and refresh token are cached. Multiple
client
> > > instances
> > > > >> can
> > > > >> > > use the same access token, and the same refresh
token. A
> thing to
> > > > >> maybe be
> > > > >> > > careful about is just properly locking the file
when making
> > > changes
> > > > >> to it.
> > > > >> > > For initial access token you have to explicitly add
it, and
> > > assign it
> > > > >> an
> > > > >> > > alias - you can use any random value there if you
want. For
> > > > >> registration
> > > > >> > > access token they are automatically associated with
initial
> token
> > > > >> they were
> > > > >> > > initiated from - again there should be no
collision.
> > > > >> > >
> > > > >> >
> > > > >> > I like the option to have two approaches as there are
two
> use-cases.
> > > > >> One is
> > > > >> > manually registering for example during development or
when
> manually
> > > > >> > configuring an application to use Keycloak. Another is
> scripted.
> > > Even
> > > > >> for
> > > > >> > scripted you may quite likely want to just add service
account
> > > > >> credentials
> > > > >> > or initial access token directly to ~/.keycloak/ rather
than
> pass
> > > these
> > > > >> to
> > > > >> > the commands.
> > > > >> >
> > > > >> > Registration access tokens are associated with a client,
not an
> > > initial
> > > > >> > access token. Also, remember the registration access
token is
> > > changed on
> > > > >> > updates.
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > > What alternative mechanism would you suggest for
storing
> 'session'
> > > > >> info?
> > > > >> > > We want to support Windows as well so it can't
be Unix / Bash
> > > > >> specific.
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>> * The tool should be idempotent.
> > > > >> > >>>
> > > > >> > >>> * You suggest storing tokens in a cache,
how do you plan on
> > > > >> handling the
> > > > >> > >>> case where a token expires before all
operations are
> complete?
> > > > >> > >>>
> > > > >> > >>> * We also initially took the approach of
caching tokens but
> > > > >> discovered
> > > > >> > >>> the complexity did not justify the minimal
cost of
> obtaining a
> > > new
> > > > >> token
> > > > >> > >>> for each invocation. This greatly
simplified the code with
> very
> > > > >> little
> > > > >> > >>> performance impact.
> > > > >> > >>>
> > > > >> > >>> * You do not mention what type of client
you're
> registering. I'm
> > > > >> > >>> assuming it's OpenID but SAML clients
(SP) are equally
> > > important.
> > > > >> The
> > > > >> > >>> tool must be able to handle both.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> Marko is probably referring to the Keycloak
client
> > > representation,
> > > > >> which
> > > > >> > >> can be either OpenID or SAML. However, we also
need to
> support
> > > OpenID
> > > > >> > >> Connect client descriptions as well as SAML
entity
> descriptors as
> > > > >> both are
> > > > >> > >> supported by client reg services.
> > > > >> > >>
> > > > >> > >
> > > > >> > > The CLI needs to know which of the client
registration
> providers
> > > (REST
> > > > >> > > endpoints) to use - there are four as described in
the Client
> > > > >> Registration
> > > > >> > > documentation (
> > > > >> > >
> > > > >>
> > >
>
http://keycloak.github.io/docs/userguide/keycloak-server/html/client-regi...
> > > > >> > > )
> > > > >> > >
> > > > >> > > Ideally the input format of the file could be
recognised as
> only
> > > > >> > > appropriate for one of these providers, and the
correct
> provider
> > > then
> > > > >> > > automatically used. But maybe we need a way to
explicitly
> tell the
> > > > >> tool
> > > > >> > > what provider to use. For example:
> > > > >> > >
> > > > >> > > kc new --type default --name test-app --enabled
true
> --base-url
> > > > >> > >
http://localhost:8480/test-app --redirect-uri
'
> > > > >> > >
http://localhost:8480/test-app/*' --admin-url
> > > > >> > >
http://localhost:8480/test-app/logout --secret
password | kc
> > > create
> > > > >> > > --type default -f -
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > Having to set --type for both creating a
description (kc
> new), and
> > > > >> > > pushing it to the server (kc create) is not ideal.
> > > > >> > >
> > > > >> >
> > > > >> > We can detect the difference between Keycloak client
rep, SAML
> and
> > > OIDC
> > > > >> > json that's pretty trivial and we should do that.
However,
> there
> > > needs
> > > > >> to
> > > > >> > be a way to specify the provider as well as there could
be
> custom
> > > > >> providers
> > > > >> > added.
> > > > >> >
> > > > >> > For getting the client it should by default return
Keycloak
> client
> > > > >> > representation, but we need an option to be able to
specify the
> > > > >> provider so
> > > > >> > it can return the client installation file instead.
> > > > >> >
> > > > >> > With regards to creating by passing arguments rather
than a
> file
> > > that
> > > > >> > should only support client representation files.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * I don't see anything in your document
on how to specify
> the
> > > SAML
> > > > >> > >>> metadata.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > > Instead of piping in my-client.json, you would pipe
in
> > > > >> my-client-saml.xml,
> > > > >> > > possibly requiring an extra --type specifier as
described
> above.
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>> * I don't see anything in your document
on how the user
> > > modifies the
> > > > >> > >>> client. It appears as if you are retrieving
a
> > > ClientRepresentation
> > > > >> JSON
> > > > >> > >>> document and expecting the user to edit it
in a text editor
> > > which
> > > > >> will
> > > > >> > >>> then be sent back. That won't work for
non-interactive
> > > installs. It
> > > > >> also
> > > > >> > >>> presumes the user knows how to read and
modify the JSON.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> It would be nice to be able to set specific
fields without
> > > having to
> > > > >> > >> modify JSON. We discussed that for the Admin
CLI, but we
> should
> > > > >> probably
> > > > >> > >> also add it to the client reg CLI
> > > > >> > >>
> > > > >> > >
> > > > >> > > It would be very valuable to see some of the
usecases, what
> kind
> > > of
> > > > >> > > changes people do on existing clients.
> > > > >> > >
> > > > >> >
> > > > >> > We should support anything that is in client
representation. It
> > > should
> > > > >> just
> > > > >> > be a generic way to change json fields. For example:
> > > > >> >
> > > > >> > # kcreg update <client id> --set enabled=false
--set baseUrl=
> > > > >> >
http://new-url/myapp --remove rootUrl
> > > > >> >
> > > > >> > This would get the KC client rep, change the
corresponding
> fields
> > > and
> > > > >> send
> > > > >> > it back.
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * Keycloak currently has a few problems
with client
> > > registration and
> > > > >> > >>> it's necessary to modify the client
before it will work
> > > correctly.
> > > > >> We
> > > > >> > >>> currently do this via the REST API. How are
you planning on
> > > handling
> > > > >> > >>> these issues in your installer? It would be
nice if the
> > > installer
> > > > >> was
> > > > >> > >>> aware of the Keycloak version and could
apply "fix-ups" as
> > > needed
> > > > >> based
> > > > >> > >>> on the version.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> AFAIK you have one problem? About not all
redirect URI
> included
> > > from
> > > > >> the
> > > > >> > >> SAML entity descriptor. Is that what you are
referring to
> or do
> > > you
> > > > >> have
> > > > >> > >> other problems?
> > > > >> > >>
> > > > >> > >> In either case fix-ups should be performed by
the client
> > > registration
> > > > >> > >> services, not in the CLI.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * Keycloak has two ways to register a
client (client
> > > registration
> > > > >> > >>> service vs. REST API). The two methods do
not produce the
> same
> > > > >> client
> > > > >> > >>> configuration (I suspect because they do
not share common
> code
> > > in
> > > > >> the
> > > > >> > >>> server). How are you planning on addressing
the
> discrepancies?
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> The task of the CLI is not to address any
discrepancies.
> It's
> > > just
> > > > >> > >> invoking the client reg services. Any
discrepancies should
> be
> > > > >> handled by
> > > > >> > >> the client reg services themselves. Have you
created JIRA's
> for
> > > > >> these or
> > > > >> > >> can you list them to us?
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * The tool should be smart enough to
produce a working
> client
> > > > >> without
> > > > >> > >>> manual intervention (i.e. the need to run
admin cli
> commands
> > > > >> afterwards
> > > > >> > >>> to fix problems). Most admins won't
know how to tweak the
> > > > >> configuration.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> Can you list any you are aware of? Same comment
as above
> applies
> > > > >> though,
> > > > >> > >> it's the responsibility of the client reg
services to handle
> > > this,
> > > > >> not the
> > > > >> > >> CLI. Otherwise you'd have different
behavior if you invoke
> > > client reg
> > > > >> > >> services directly rather than through the CLI.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> * The tool should not have significant
dependencies.
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >> It'll be a fat-jar and will have a single
dependency on the
> JVM.
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>>
> > > > >> > >>> Those are the thoughts off the top of my
head, as you fill
> out
> > > the
> > > > >> > >>> details I'll continue to review. Recall
the plan of record
> is
> > > for
> > > > >> > >>> Keycloak to provide such tools which we
will then utilize.
> The
> > > > >> > >>> keycloak-httpd-client-install tool is a
stop-gap solution
> until
> > > such
> > > > >> > >>> time as "offical" tools become
available.
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>>
> > > > >> > >>> --
> > > > >> > >>> John
> > > > >> > >>>
_______________________________________________
> > > > >> > >>> keycloak-dev mailing list
> > > > >> > >>> keycloak-dev(a)lists.jboss.org
> > > > >> > >>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >> > >>>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >
> > > > >>
> > > > >> > _______________________________________________
> > > > >> > keycloak-dev mailing list
> > > > >> > keycloak-dev(a)lists.jboss.org
> > > > >> >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >>
> > > > >>
> > > > >> --
> > > > >>
> > > > >> abstractj
> > > > >> PGP: 0x84DC9914
> > > > >>
> > > > >
> > > > >
> > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > >
>
> --
>
> abstractj
> PGP: 0x84DC9914
>