Setting up an OpenStack federated env using TripleO and Shibboleth

The OpenStack Federated Identity feature has been present for a while and has reached a good mature state.

In this post we will use TripleO to setup a real (minimal) OpenStack deployment and later we will manually setup a WebSSO environment using Shibboleth as service provider tool and test it against TestShib.

Installing OpenStack using TripleO

TripleO is a tool used to install and manage OpenStack deployments. The coolest part of it is that it uses OpenStack services (nova, ironic, heat, ...) in order to install a real OpenStack cloud - it is almost like a meta-OpenStack :)

A quick and easy way to use TripleO is via the tripleo-quisktack project and is what will be used by us. It is possible to make all kinds of complex and fancy deployments using it, but we will keep it simple and use a default template that will deploy 1 controller and 1 compute nodes.

  • NOTE: it is not the goal of this post to explain TripleO internals. It is assumed that the reader is familiar with terms such as undercloud and overcloud.

tripleo-quickstart uses Ansible, so the quickstart command is usually not ran inside the target host. To install the tool requirements is as simple as:

$ git clone https://github.com/openstack/tripleo-quickstart.git
$ cd tripleo-quickstart
$ sudo bash quickstart.sh --install-deps

Finally, to install OpenStack in a host, you can run:

$ bash quickstart.sh --tags all $TRIPLEO_HOST

The --tags all parameter is important since it states that both undercloud and overcloud will be deployed.

  • NOTE: it is assumed that name resolution is configured, in this post, the overcloud controller host will be called $CONTROLLER_HOST.

  • NOTE: we are assuming the usage of a RPM based distribution. A fresh CentOS 7 install will be used as base throughout this post.

Install and configure Shibboleth Service Provider (SP)

Install Shibboleth

The Shibboleth SP must be installed/configured in all overcloud controller nodes.

For CentOS 7, we can use the following repository:

# curl -o /etc/yum.repos.d/security:shibboleth.repo http://download.opensuse.org/repositories/security://shibboleth/CentOS_7/security:shibboleth.repo

Now we can install Shibboleth SP:

# yum install shibboleth -y

Configure httpd

The Shibboleth httpd configuration is placed at /etc/httpd/conf.d/shib.conf upon install.

We need to add the following entry in it:

<Location /v3/auth/OS-FEDERATION/websso/saml2>  
  ShibRequestSetting requireSession 1
  AuthType shibboleth
  ShibRequireSession On
  ShibExportAssertion Off
  Require valid-user
</Location>  

And modify the Shibbolleth.sso one to:

<Location /Shibboleth.sso>  
  SetHandler shib
</Location>  

We also need to update the /etc/httpd/conf/httpd.conf file and add the following:

UseCanonicalName On  
  • NOTE: setting the above means that httpd will always respond with the ServerName so it will hide any IPs or ports - this may be an issue since keystone usually runs behind a port (5000 and/or 35357). In any redirects made or configs generated by Shibboleth we will need to manually fix the port so it will be handled by keystone when necessary.

Configure Shibboleth

Shibboleth configuration files are placed at the /etc/shibboleth folder, we are specially interested in the /etc/shibboleth/shibboleth2.xml file.

TestShib provides a configuration generator and it is currently located at https://www.testshib.org/configure.html, there you may edit the hostname that will be used in the SP's entity ID. Remember that hostname should point to your overcloud controller somehow.

You can replace the /etc/shibboleth/shibboleth2.xml file with the content generated in TestShib's website.

Upload local Shibboleth SP metadata to TestShib

  • NOTE: you might need to properly configure Shibboleth in SELinux.

To retrieve your Shibboleth SP metadata we need to access the /Shibboleth.sso/Metadata URL in your overcloud controller node. Then, we upload it in TestShib's website at https://www.testshib.org/register.html (as of today).

Configure keystone

Now we need to configure keystone to proper handle the WebSSO workflow. Keystone's configuration file is located at /etc/keystone/keystone.conf:

  • Add saml2 as authentication method.
[auth]

...

methods = external,password,token,saml2,oauth1  
  • Add Shib-Identity-Provider as remote ID attribute. This is the field that keystone will check to match the IdP's entity ID.
[federation]

...

remote_id_attribute = Shib-Identity-Provider  
  • Configure local horizon as trusted dashboard.
[federation]

...

trusted_dashboard = http://$CONTROLLER_HOST/dashboard/auth/websso/  

Configure keystone to authenticate TestShib users

The Federation API is only available in keystone v3. In order to use keystone's v3 API, we need to modify our overcloudrc file adding the following:

# OS_AUTH_URL must point to /v3 not /v2.0
export OS_AUTH_URL=http://$CONTROLLER_HOST:5000/v3

# OS_PROJECT_NAME instead of OS_TENANT_NAME
export OS_PROJECT_NAME=admin

export OS_USER_DOMAIN_NAME=Default  
export OS_PROJECT_DOMAIN_NAME=Default  
export OS_IDENTITY_API_VERSION=3  

Create a keystone mapping

Keystone's mapping engine is used to map external users to internal keystone concepts such as groups. For that, we need to create a mapping rule like the following:

[
  {
    "local": [
      {
        "user": {
          "name": "{0}",
          "domain": {"name": "Default"}
        }
      },
      {
        "group": {
          "id": "$GROUP_ID"
        }
      }
    ],
    "remote": [
      {
        "type": "REMOTE_USER"
      }
    ]
  }
]

In the mapping rule above, we are using the REMOTE_USER attribute to map into a group in keystone. The mapped user will have the same value as in the REMOTE_USER attribute and will belong to the Default domain. For that, we need to create such a group and assign a role for it in a project.

  • Create a group called testshib_users:
$ openstack group create testshib_users
  • Assign the _member_ role in the admin project for the group we just created:
$ openstack role add --project admin --group testshib_users _member_

Now we can replace the $GROUP_ID in the mapping rules above with the testshib_users ID, place it in a file and create the mapping:

$ openstack mapping create --rules testshib_mapping.json testshib_mapping

Finally, we can create an identity provider (that will represent TestShib IdP) and a protocol that will tie together the IdP and the mapping:

$ openstack identity provider create --remote-id https://idp.testshib.org/idp/shibboleth testshib
$ openstack federation protocol create --identity-provider testshib --mapping testshib_mapping saml2

Configure horizon

The last step is horizon's configuration. Here we prepare horizon to be able to perform the WebSSO authentication, it can be done by editing the /opt/stack/horizon/openstack_dashboard/local/local_settings file:

WEBSSO_ENABLED = True  
WEBSSO_CHOICES = (  
 ("credentials", _("Keystone Credentials")),
 ("saml2", _("TestShib SAML")),
 )
WEBSSO_INITIAL_CHOICE="saml2"  
OPENSTACK_API_VERSIONS = {  
 "identity": 3
}
OPENSTACK_KEYSTONE_URL="http://$CONTROLLER_HOST:5000/v3"  

Restart httpd for the changes take place:

# systemctl restart httpd.service

Test everything

Access the overcloud horizon and try to log in using TestShib SAML:

We then, are redirected to the TestShib IdP page:

Enter the credentials and click on Login. Upon success, we are redirected back your Shibboleth SP that will forward the SAML assertion to keystone. If everything works as expected, a ephemeral user is created and we are redirected back to horizon with a valid token:

I'd like to thank bigjools, lots of information were taken from SAML Federation with Openstack.

comments powered by Disqus