Tripleo HA Federation Proof-of-Concept

Keystone has supported identity federation
for several releases. I have been working on a proof-of-concept integration of identity federation in a TripleO deployment. I was able to successfully login to Horizon via WebSSO, and want to share my notes.

A federation deployment requires changes to the network topology, Keystone, the HTTPD service, and Horizon. The various OpenStack deployment tools will have their own ways of applying these changes. While this proof-of-concept can’t be called production-ready, it does demonstrate that TripleO can support Federation using SAML. From this proof-of-concept, we should be to deduce the necessary steps needed for a production deployment.

Keycloak
– Actually an alpha build of Red Hat SSO, running on the base OS. This was fronted by Apache HTTPD, and proxied through ajp://localhost:8109
. This gave me HTTPS support using the CA Certificate from the IPA server. This will be important later when the controller nodes need to talk to the identity provider to set up metadata.

In addition, I did some sanity checking of the cluster, but deploying the overcloud using the quickstart helper script, and tore it down using heat stack-delete overcloud
.

Reproducing Results

When doing development testing, you can expect to rebuild and teardown your cloud on a regular basis. When you redeploy, you want to make sure that the changes are just the delta from what you tried last time. As the number of artifacts grew, I found I needed to maintain a repository of files that included the environment passed to openstack overcloud deploy
. To manage these, I create a git repository in /home/stack/deployment
. Inside that directory, I copied the overcloud-deploy.sh
and deploy_env.yml
files generated by the overcloud, and modified them accordingly.

In my version of overcloud-deploy.sh
, I wanted to remove the deploy_env.yml
generation, to avoid confusion during later deployments. I also wanted to preserve the environment file across deployments (and did not want it in /tmp)
. This file has three parts: the Keystone configuration values, HTTPS/Network setup, and configuration for a single node deployment. This last part was essential for development, as chasing down fixes across three HA nodes was time-consuming and error prone. The DNS server value I used is particular to my deployment, and reflects the IPA server running on the base host.

For reference, I’ve included those files at the end of this post.

Identity Provider Registration and Metadata

While it would have been possible to run the registration of the identity provider on one of the nodes, the Heat-managed deployment process does not provide a clean way to gather those files and package them for deployment to other nodes. While I deployed on a single node for development, it took me a while to realize that I could do that, and had already worked out an approach to call the registration from the undercloud node, and produce a tarball.

As a result, I created a script, again to allow for reproducing this in the future:

This does not quite generate the right paths, as it turns out that the $basename
is not quite what we want, so I had to post-edit the generated file: rhsso/etc/httpd/conf.d/v3_mellon_keycloak_openstack.conf

While I created a tarball that I then manually deployed, the preferred approach would be to use tripleo-heat-templates/puppet/deploy-artifacts.yaml
to deploy them. The problem I faced is that the generated files include Apache module directives from mod_auth_mellon
. If mod_auth_mellon
has not been installed into the controller, the Apache server won’t start, and the deployment will fail.

Federation Operations

The Federation setup requires a few calls. I documented them in Rippowam
, and attempted to reproduce them locally using Ansible and the Rippowam code. I was not a purist though, as A)
I needed to get this done and B)
the end solution is not going to use Ansible anyway. The general steps I performed:

yum install mod_auth_mellon

Copy over the metadata tarball, expand it, and tweak the configuration (could be done prior to building the tarball).

Important
: Make sure that the auth URL is using a FQDN name that matches the value in the signed certificate.

Redirect Support for SAML

The several differences between how HTTPD and HA Proxy operate require us to perform certain configuration modifications. Keystone runs internally over HTTP, not HTTPS. However, the SAML Identity Providers are public, and are transmitting cryptographic data, and need to be protected using HTTPS. As a result, HA Proxy needs to expose an HTTPS-based endpoint for the Keystone public service. In addition, the redirects that come from mod_auth_mellon
need to reflect the public protocol, hostname, and port.

The solution I ended up with involved changes on both sides:

In haproxy.cfg
, I modified the keystone public stanza so it looks like this:

While this was necessary, it also proved to be insufficient. When the signed assertion from the Identity Provider is posted to the Keystone server, mod_auth_mellon
checks that the destination value matches what it expects the hostname should be. Consequently, in order to get this to match in the file:

Note that the protocol is set to https
even though the Keystone server is handling HTTP. This might break elswhere. If if does, then the Keystone configuration in Apache may have to be duplicated.

Federation Mapping

For the WebSSO login to successfully complete, the user needs to have a role on at least one project. The Rippowam mapping file maps the user to the Member
role in the demo
group, so the most straightforward steps to complete are to add a demo group, add a demo project, and assign the Member
role on the demo project to the demo group. All this should be done with a v3 token: