This is the documentation for CDH 4.7.1. Documentation for other versions is available at Cloudera Documentation.

Cloudera Manager 4 and CDH 4 have reached End of Maintenance (EOM) on August 9, 2015. Cloudera will not support or provide patches for any of the Cloudera Manager 4 or CDH 4 releases after that date.

Hue Security Configuration

This section describes how to use Hue, Hue Shell, and CDH4 with Kerberos security on your Hadoop cluster:

To enable Hue to work with Kerberos security on your Hadoop cluster, make sure you perform the installation and configuration steps in Configuring Hadoop Security in CDH4.

Configuring Hue to Support Hadoop Security using Kerberos

You can configure Hue in CDH4 to support Hadoop security on a cluster using Kerberos.

To configure the Hue server to support Hadoop security using Kerberos:

  1. Create a Hue user principal in the same realm as the Hadoop cluster of the form:
    kadmin: addprinc -randkey hue/

    where: hue is the principal the Hue server is running as is the fully-qualified domain name (FQDN) of your Hue server YOUR-REALM.COM is the name of the Kerberos realm your Hadoop cluster is in

  2. Create a keytab file for the Hue principal using the same procedure that you used to create the keytab for the hdfs or mapred principal for a specific host. You should name this file hue.keytab and put this keytab file in the directory /etc/hue on the machine running the Hue server. Like all keytab files, this file should have the most limited set of permissions possible. It should be owned by the user running the hue server (usually hue) and should have the permission 400.
  3. To test that the keytab file was created properly, try to obtain Kerberos credentials as the Hue principal using only the keytab file. Substitute your FQDN and realm in the following command:
    $ kinit -k -t /etc/hue/hue.keytab hue/
  4. In the /etc/hue/hue.ini configuration file, add the following lines in the sections shown. Replace the kinit_path value, /usr/kerberos/bin/kinit, shown below with the correct path on the user's system.
     # Path to Hue's Kerberos keytab file
     # Kerberos principal name for Hue
     # add kinit path for non root users
     beeswax_server_host=<FQDN of Beeswax Server>
       ## server_host=localhost
       ## impala_principal=impala/
     # Enter the host and port on which you are running the Hadoop NameNode
     # Thrift plugin port for the name node
     ## thrift_port=10090
     # Configuration for MapReduce JobTracker
     # ------------------------------------------------------------------------
     # Enter the host on which you are running the Hadoop JobTracker
     # Thrift plug-in port for the JobTracker
     ## thrift_port=9290

    In the /etc/hue/hue.ini file, verify the following: — Make sure the jobtracker_host property is set to the fully-qualified domain name of the host running the JobTracker. The JobTracker host name must be fully-qualified in a secured environment. — Make sure the fs.defaultfs property under each [[hdfs_clusters]] section contains the fully-qualified domain name of the file system access point, which is typically the NameNode. — Make sure the FQDN specifed for the Beeswax Server is the same as the FQDN specified in the hue_principal configuration. Without this, Beeswax will not work with security enabled.

  5. In the /etc/hadoop/conf/core-site.xml configuration file on all of your cluster nodes, add the following lines:
    <!-- Hue security configuration -->
      <value>*</value> <!-- A group which all users of Hue belong to, or the wildcard value "*" -->

    Make sure you change the /etc/hadoop/conf/core-site.xml configuration file on all of your cluster nodes.

  6. If Hue is configured to communicate to Hadoop via HttpFS, then you must add the following properties to httpfs-site.xml:
  7. Add the following properties to the Oozie server oozie-site.xml configuration file in the Oozie configuration directory:
  8. Restart the JobTracker to load the changes from the core-site.xml file.
    $ sudo service hadoop-0.20-mapreduce-jobtracker restart
  9. Restart Oozie to load the changes from the oozie-site.xml file.
    $ sudo service oozie restart
  10. Restart the NameNode, JobTracker, and all DataNodes to load the changes from the core-site.xml file.
    $ sudo service hadoop-0.20-(namenode|jobtracker|datanode) restart

Running Hue Shell against a Secure Cluster

If you are running Hue Shell against a secure cluster, you must make sure that the directory specified by shell_delegation_token_dir in the hue.ini configuration file is writable by the user running the Hue server in the local file system on the Hue machine.

Hue Security Enhancements

Restricting the Cipher List

Cipher list support with HTTPS can be restricted by specifying the ssl_cipher_list configuration property under the [desktop] section in hue.ini.


Default: !aNULL:!eNULL:!LOW:!EXPORT:!SSLv2

Secure Cookies

Secure session cookies can be enable by specifying the secure configuration property under the [desktop]>[[session]] section in hue.ini. Additionally, you can set the http-only flag for cookies containing users' session IDs.


The cookie containing the users' session ID will be secure. Should only be enabled with HTTPS.

Default: false

Session Timeout

Session timeouts can be set by specifying the ttl configuration property under the [desktop]>[[session]] section in hue.ini.


The cookie containing the users' session ID will expire after this amount of time in seconds.

Default: 60*60*24*14

Secure Database Connection

Connections vary depending on the database. Hue uses different clients to communicate with each database internally. They all specify a common interface known as the DBAPI version 2 interface. Client specific options, such as secure connectivity, can be passed through the interface. For example, for MySQL you can enable SSL communication by specifying the options configuration property under the desktop>[[database]] section in hue.ini.


URL Redirect Whitelist

Restrict the domains or pages to which Hue can redirect users. The redirect_whitelist property can be found under the [desktop] section in hue.ini.


For example, to restrict users to your local domain and FQDN, the following value can be used:


Configuring Hue for SAML

This section describes the configuration changes required to use Hue with SAML 2.0 (Security Assertion Markup Language) to enable single sign-on (SSO) authentication.

The SAML 2.0 Web Browser SSO profile has three components: a Security Provider, a User Agent and an Identity Provider. In this case, Hue is the Service Provider (SP), you can use an Identity Provider (IdP) of your choice, and you are the user acting through your browser (User Agent). When a user requests access to an application, Hue uses your browser to send an authentication request to the Identity Provider which then authenticates the user and redirects them back to Hue .

This blog post guides users through setting up SSO with Hue, using the SAML backend and Shibboleth as the Identity Provider.

  Note: The following instructions assume you already have an Identity Provider set up and running.

Step 1: Install swig and openssl packages

Install swig and openssl. For example, on RHEL systems, use the following commands:

yum install swig
yum install openssl

Step 2: Install libraries to support SAML in Hue

Install the djangosaml2 and pysaml2 libraries to support SAML in Hue. These libraries are dependent on the xmlsec1 package to be installed and available on the machine for Hue to use. Follow these instructions to install the xmlsec1 package on your system.

RHEL, CentOS and SLES:

For RHEL, CentOS and SLES systems, the xmlsec1 package is available for download from the EPEL repository. For example, on CentOS, use the following commands to install the package, substituting the version in the package URL with the one required for your system:
rpm -Uvh
yum install xmlsec1

Oracle Linux:

For Oracle Linux systems, download the xmlsec1 package from and execute the following commands:
tar -xvzf xmlsec1-<version>.tar.gz
cd xmlsec1-<version>
./configure && make
sudo make install
  Important: The xmlsec1 package must be executable by the user running Hue.

You should now be able to install djangosaml and pysaml2 on your machines.

build/env/bin/pip install -e git+
build/env/bin/pip install -e git+

Step 3: Update the Hue configuration file

Several configuration parameters need to be updated in Hue's configuration file, hue.ini to enable support for SAML. The table given below describes the available parameters for SAML in hue.ini under the [libsaml] section.


xmlsec_binary This is a path to the xmlsec_binary, an executable used to sign, verify, encrypt and decrypt SAML requests and assertions. This program should be executable by the user running Hue.
create_users_on_login Create Hue users received in assertion response upon successful login. The value for this parameter can be either "true" or "false".
required_attributes Attributes Hue asks for from the IdP. This is a comma-separated list of attributes. For example, uid, email and so on.
optional_attributes Optional attributes Hue can ask for from the IdP. Also a comma-separated list of attributes.
metadata_file This is a path to the IdP metadata copied to a local file. This file should be readable.
key_file Path to the private key used to encrypt the metadata. File format .PEM
cert_file Path to the X.509 certificate to be sent along with the encrypted metadata. File format .PEM
user_attribute_mapping Mapping from attributes received from the IdP to the Hue's django user attributes. For example, {'uid':'username', 'email':'email'}.
logout_requests_signed Have Hue initiated logout requests be signed and provide a certificate.

Step 3a: Update the SAML metadata file

Update the metadata file pointed to by your Hue configuration file, hue.ini. Check your IdP documentation for details on how to procure the XML metadata and paste it into the <metadata_file_name>.xml file at the location specified by the configuration parameter metadata_file.

For example, if you were using the Shibboleth IdP, you would visit https://<IdPHOST>:8443/idp/shibboleth, copy the metadata content available there and paste it into the Hue metadata file.


You may have to edit the content copied over from your IdP's metadata file in case of missing fields such as port numbers (8443), from URLs that point to the IdP.

Step 3b: Private key and certificate files

To enable Hue to communicate with the IdP, you will need to specify the location of a private key, for the, key_file property, that can be used to sign requests sent to the IdP. You will also need to specify the location of the certificate file, for the cert_pem property, which you will use to verify and decrypt messages from the IdP.

  Note: The key and certificate files specified by the key_file and cert_file parameters must be .PEM files.

Step 3c: Configure Hue to use SAML Backend

To enable SAML to allow user logins and create users, update the backend configuration property in hue.ini to use the SAML authentication backend. You will find the backend property in the [[auth]] sub-section under [desktop].
Here is an example configuration of the [libsaml] section from hue.ini.

Step 4: Restart the Hue server

Use the following command to restart the Hue server.

sudo service hue restart
This page last updated August 5, 2015