Enabling SSO Authentication in Hue

There’s good news for users of Hue, the open source web UI that makes Apache Hadoop easier to use: A new SAML 2.0-compliant backend, which is scheduled to ship in the next release of the Cloudera platform, will provide a better authentication experience for users as well as IT.

With this new feature, single sign-on (SSO) authentication can be achieved instead of using Hue credentials – thus, user credentials can be managed centrally (a big benefit for IT), and users needn’t log in to Hue if they have already logged in to another Web application sharing the SSO (a big benefit for users).

Here’s a demo that shows this experience:

Next, we’ll explore some details about how this new infrastructure works and then offer a quick example that illustrates the authentication process.

The Basics

There are two basic components in SAML 2.0: the service provider (SP) and identity provider (IdP). The typical flow from SP to IdP is illustrated by the following image.

Figure 1. SAML architecture (from http://en.wikipedia.org/wiki/SAML_2.0; available under public domain)

In this process, Hue acts as an SP with an assertion consumer service (ACS). An assertion indicates that the IdP has authenticated a user. It optionally contains information about the user’s privileges and other attributes. Thus, Hue communicates with the IdP to authenticate users. Also, Hue provides two 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 after it has authenticated them.

Creating Users

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

Example

Next, let’s review a how-to based on making Hue communicate via SAML with a Shibboleth IdP. Shibboleth is an open source project that implements federated identity support through SAML 2.0.

Environment

This example runs on CentOS 6.4 and assumes the following projects are installed and configured:

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

  • Releases the UID attribute with assertions (makes it available to requesters)
  • Available over SSL on port 8443
  • Provides authentication via LDAP through OpenDS
  • Connects 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.
  • Uses the UsernamePassword handler and provides very obvious feedback that all components are configured appropriately
  • Accessible from all IP addresses

OpenDS was installed and 2,000 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:

 

The above commands will also install:

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

Note: The SAML libraries are dependent on xmlsec1 being installed and available on the machine. For RHEL or CentOS:

 

Hue must be configured as an SP and use the SAML authentication backend. Because Hue acts as the SP, you must configure it to communicate with the IdP in hue.ini:

 

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

The metadata_file is set to the file containing the IdP metadata (/tmp/metadata.xml). You can create it 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 hue.ini.

Parameter

Description

xmlsec_binary

Xmlsec1 binary path; 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 the IdP

optional_attributes

Optional attributes to ask for from the IdP

metadata_file

IdP metadata in the form of a file; generally an XML file containing metadata that the IdP generates

key_file

Private key to encrypt metadata

cert_file

Signed certificate to send along with encrypted metadata

user_attribute_mapping

Mapping from attributes in the response from the IdP to django user attributes


SAML Backend for Logging in

You have to use the SAML authentication backend so that users can login and be created:

 

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:

 

Figure 2. Shibboleth login screen after attempting to access /about

After logging in, Hue is readily available and visible!

Conclusion

As you can probably appreciate, providing SSO support through SAML helps IT 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 get the same permissions and adhere to the same rules as other users across the enterprise.

Have any suggestions? Feel free to tell us what you think through hue-user, at @gethue, or via our community discussion forum for Hue.

Filed under:

1 Response
  • joe / October 18, 2013 / 11:22 AM

    Great work guys! In the meantime you can use the PAM backend in Hue to achieve SSO — I have found this works quite well especially when the Hue server has ActiveDirectory/LDAP login configured.

Leave a comment


− one = 8