SSO with Hue: new SAML backend

Published on 25 September 2013 in Development - 4 minutes read - Last modified on 19 April 2021

A new SAML 2.0 backend is under development to provide a better authentication experience in Hue. Rather than signing in using Hue credentials, single sign-on (SSO) authentication can be achieved with this new backend.

The Basics

In SAML 2.0, there are 2 basic components: the Service Provider (SP) and Identity Provider (IdP). The typical flow from SP to IdP is made obvious in following image.

image

SAML architecture from http://en.wikipedia.org/wiki/SAML_2.0.

Hue acts as a service provider with an assertion consumer service (ACS). It communicates with the IdP to authenticate users. Hue also provides a couple of URLs that enable communication with the IdP:

  • “/saml2/metadata”
  • “/saml2/acs”

The IdP will contact the metadata URL for information on the SP. For example, the ACS URL is described in metadata. The ACS URL is the consumer of assertions from the IdP. The IdP will redirect users to the ACS URL once it has authenticated them.

Users

When a user logs into Hue through the SAML backend, a new user is created in Hue if it does already not exist. This logic is almost the same as the LdapBackend. It is also configurable via the create_users_on_login parameter.

Demo

The following is a demo of how to setup Hue to communicate via SAML with a Shibboleth IdP.

Environment

This demo is performed on CentOS 6.4 and assumes the following projects have been installed and configured:

Shibboleth IdP is installed to “/opt/shibboleth-idp” and has the following custom configurations:

  • Release the UID attribute with assertions.
  • Available over SSL on port 8443.
  • Provide authentication via LDAP through OpenDS.
  • Connect to a relying party that contains metadata about the SP. In this case, the relying party is Hue and its metadata URL is “/saml2/metadata”.
  • Use the UsernamePassword handler. It provides very obvious feedback that all components have been configured appropriately.
  • Available to all IPs.

OpenDS was installed and 2000 users were automatically generated. Then, a user “test” was added with the password “password”.

Preparing Hue

The libraries that support SAML in Hue must be installed:

build/env/bin/pip install -e git+https://github.com/abec/pysaml2@HEAD#egg=pysaml2

build/env/bin/pip install -e git+https://github.com/abec/djangosaml2@HEAD#egg=djangosaml2

The above commands will also install:

  • decorator
  • python-memcached
  • repoze.who
  • zope.interface

Note: The SAML libraries are dependent on xmlsec1 being available on the machine. This will be need to be installed and readily available for Hue to use.

Configuring Hue

Hue must be configured as a SP and use the SAML authentication backend.

1. Hue as a Service Provider

In the SAML 2.0 architecture, Hue acts as the SP. As such, it must be configured to communicate with the IdP in the hue.ini:

[libsaml]
xmlsec_binary=/opt/local/bin/xmlsec1
metadata_file=/tmp/metadata.xml
key_file=/tmp/key.pem
cert_file=/tmp/cert.pem

The key_file and cert_file can be copied from the Shibboleth IdP credentials directory (“/opt/shibboleth-idp/credentials/”). The files idp.key and kdp.crt correspond to cert_file and key_file, respectively. These files should already be in PEM format, so for purposes of this demo, they are renamed to key.pem and cert.pem.

The metadata_file is set to the file containing the IdP metadata (“/tmp/metadata.xml”). This can be created from the XML response of “http://:8443/idp/shibboleth/”. The XML itself may require some massaging. For example, in some fields, the port 8443 is missing from certain URLs.

The table below describes the available parameters for SAML in the hue.ini.

Parameter                  Description

xmlsec_binary                Xmlsec1 binary path. This program should be executable by the user running Hue.
create_users_on_login        Create users received in assertion response upon successful authentication and login.
required_attributes          Required attributes to ask for from IdP.
optional_attributes          Optional attributes to ask for from IdP.
metadata_file                IdP metadata in the form of a file. This is generally an XML file containing metadata that the Identity Provider generates.
key_file                     Private key to encrypt metadata with.
cert_file                    Signed certificate to send along with encrypted metadata.
user_attribute_mapping       A mapping from attributes in the response from the IdP to django user attributes.

Hue SAML configuration parameters.

 

2. SAML Backend for Logging-in

The SAML authentication backend must be used so that users can login and be created:

[desktop]
  [[auth]]
  backend=libsaml.backend.SAML2Backend

SAML and Hue in Action

Now that Hue has been setup to work with the SAML IdP, attempting to visit any page redirects to Shibboleth’s login screen:

image

Shibboleth login screen after attempting to access /about.

After logging in, Hue is readily available and visible!

Summary

Providing SSO support through SAML helps enterprises by enabling centralized authentication. From a user’s perspective, life is easier because it removes the burden of password management. After a user has logged in, they adhere to the same permissions and rules as other users.

Have any suggestions? Feel free to tell us what you think through hue-user or at @gethue.


comments powered by Disqus

More recent stories

26 June 2024
Integrating Trino Editor in Hue: Supporting Data Mesh and SQL Federation
Read More
03 May 2023
Discover the power of Apache Ozone using the Hue File Browser
Read More