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] -
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
>>
>
>