Trivial cleanup of some variable name copy-paste I overlooked,
making the source code for the test clearer.
Change-Id: I5a15e0733b3cf2ceb26f46a2f3d9a9f059d4f702
This includes a switch from the "legacy" style Wildfly-based image
to a new setup using Quarkus.
Because Keycloak maintainers consider H2 databases as a test/dev
only option, there are no good migration and upgrade paths short of
export/import data. Go ahead and change our deployment model to rely
on a proper RDBMS, run locally from a container on the same server.
Change-Id: I01f8045563e9f6db6168b92c5a868b8095c0d97b
The image change switches from Wildfly to Quarkus, which seems to
come with undocumented impact to H2 databases because Keycloak
maintainers consider that "for development purposes only" and not to
be used in production.
When reintroducing this change, we'll include an actual RDBMS in
order to ease future upgrade work.
Retain the added test that exercises the admin credentials and API,
but adjust it back to the path used by the legacy image.
This reverts commit fb47277a56df671bbab389ce10a89d976308d232.
Change-Id: I0908490cea852853f086e594a816343edaf6a454
When moving from DockerHub to Quay in 2022, we had to specify the
legacy container tag because something also changed with the images
themselves at that time in such a way that they no longer worked
with our configs. The legacy images ceased being updated past v19,
so specify the 19.0 tag in order to match the major version we're
running in production, and work through the necessary container
config changes before resuming upgrades to a more current version.
Change-Id: I5bf587fe3d8327c17d71908104c0896f8baf0973
Some extra steps are needed to use keycloak with a reverse proxy.
This adjusts the apache config to send the required headers and
the keycloak server config to use them.
Since the openid configuration json page is constructed entirely
from these headers (and not from static configuration), this is
a good test that the entire system is working.
Change-Id: I662dc85836d640cb732f12f39e9a61607767fcf3
This adds a keycloak server so we can start experimenting with it.
It's based on the docker-compose file Matthieu made for Zuul
(see https://review.opendev.org/819745 )
We should be able to configure a realm and federate with openstackid
and other providers as described in the opendev auth spec. However,
I am unable to test federation with openstackid due its inability to
configure an oauth app at "localhost". Therefore, we will need an
actual deployed system to test it. This should allow us to do so.
It will also allow use to connect realms to the newly available
Zuul admin api on opendev.
It should be possible to configure the realm the way we want, then
export its configuration into a JSON file and then have our playbooks
or the docker-compose file import it. That would allow us to drive
change to the configuration of the system through code review. Because
of the above limitation with openstackid, I think we should regard the
current implementation as experimental. Once we have a realm
configuration that we like (which we will create using the GUI), we
can chose to either continue to maintain the config with the GUI and
appropriate file backups, or switch to a gitops model based on an
export.
My understanding is that all the data (realms configuration and session)
are kept in an H2 database. This is probably sufficient for now and even
production use with Zuul, but we should probably switch to mariadb before
any heavy (eg gerrit, etc) production use.
This is a partial implementation of https://docs.opendev.org/opendev/infra-specs/latest/specs/central-auth.html
We can re-deploy with a new domain when it exists.
Change-Id: I2e069b1b220dbd3e0a5754ac094c2b296c141753
Co-Authored-By: Matthieu Huin <mhuin@redhat.com>
