Keycloak integration

Juraci Paixão Kröhling jpkroehling at redhat.com
Fri Dec 5 11:28:46 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

All,

I finally got some time to work a bit more on the Keycloak integration.

== TL;DR:
I'd like to get a review/comments/suggestions for the following:

Branch:
https://github.com/jpkrohling/rhq-metrics/tree/JPK-KCAuthentication-Draft

Comparison:
https://github.com/jpkrohling/rhq-metrics/compare/rhq-project:master...jpkrohling:JPK-KCAuthentication-Draft?expand=1

== Long version

A few words about Keycloak:

- - Keycloak has an authentication server, and can be deployed as a WAR
file.
- - Keycloak has also adapters, to make it easy for applications to
authenticate against an auth server. Basically, an application (WAR,
like rhq-metrics) just define the auth method as "KEYCLOAK" and the
adapter takes care of loading the configuration from keycloak.json and
intercepting all the requests to authenticate/authorize it, exposing
the principal as a regular JAAS subject. For metrics-console, there's
a javascript adapter.
- - To make it easier to get an auth server with adapters, they also
provide an "appliance" version, which includes all the bits. This is
currently based on WildFly 8.1.0.Final and will be using 8.2.0.Final
for the next release.

This effectively means that Keycloak Auth Server can be running on one
node and rhq-metrics in another. But I assume that for development,
the appliance is the easiest solution.

Keycloak has also a notion of "realms", which we are using on a
per-tenant basis: each tenant is a realm in Keycloak. In the
integration code, I'm using two realms to demonstrate the
multi-tenancy capability: "acme-roadrunner-affairs" and
"acme-other-affairs". Each represents a department inside Acme, Inc.
We can define realms as JSON files, and import them during the first
boot, which is convenient for a "getting started" scenario. The JSON
file can also be imported via the Auth Server Web UI, if
needed/required/wanted.

Inside a realm, we define applications, roles and users. By
applications, I mean "metrics-console" and "rhq-metrics", for
instance. By roles, we currently have "admin", "user" and "agent",
which were the ones I imagined as the first roles to add. By users, we
have only one standard user: "agent" (which has an "agent" role). Each
additional user self-registers during the first login.

This all means that we now have two options:
- - use the start.sh to generate random keys and certificates, so that
we don't have "default" ones (it's like having default passwords, and
I think we know how bad it is)
- - use the start.sh only for minimal stuff (copying things around and
starting Keycloak). This implies that we'd have default
passwords/secrets/keys.

I've tried to keep the start.sh as simple as possible, and most of the
things there are replacing tokens and copying things around, but I
know that this wouldn't be easy to maintain for someone who is looking
at it for the first time.

Pretty much nothing else is intrusive, but I'd appreciate feedback
there as well.

And a final note: on the metrics-console, the JavaScript code there is
as real JavaScript. I intend to re-write as TypeScript, as it seems
that's the chosen language. I'd need some time to study TypeScript,
though :-)

So, all that said, I'd like to share the following changes for
review/discussion:

Branch:
https://github.com/jpkrohling/rhq-metrics/tree/JPK-KCAuthentication-Draft

Comparison:
https://github.com/jpkrohling/rhq-metrics/compare/rhq-project:master...jpkrohling:JPK-KCAuthentication-Draft?expand=1

If you'd like to run this on your local machine, I'll need to build
Keycloak from master by yourself, as I'm using a feature that was
added this week.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUgZbuAAoJECKM1e+fkPrXZf4H/1h58HL51UyrYqqM/gPhMAt0
EcY4P8/I4HwSpAw1AO8BnR2TL+EgZc+bAZn7Nw/NrOH61eU5IGVG5+UcnqS7LIP9
m8NteACuyJhfTmKly8PNxENQ0grCjOoUpAffN97pbFoJWT/MKlzda4dAbL7aAN05
Kgz99OvqFWJMLGOtQWcvEiZBDU+OacY9NBkKXCl0ZivnN47YonA0c3SLlnG8a+34
4NErQbSpm7iENPz2ab4EbCbRduGoQtu8NtKclnweAkD3MurfRHSvRKckib0MgASM
LRE9B2nt+MMekeN6I9Q2UrTY9hP4X9xIEpWHy+KXKMI4vHb9xxyFiIC/Kly2boY=
=fVaW
-----END PGP SIGNATURE-----


More information about the rhq-devel mailing list