Configuring External Authentication for the Cloudera Navigator Data Management Component

Minimum Required Role: Navigator Administrator (also provided by Full Administrator)

Cloudera Navigator supports user authentication against Cloudera Manager user accounts and against an external service. The external service can be either LDAP or Active Directory. User authentication against Cloudera Manager user accounts requires users to have one of two Cloudera Manager user roles, either Full Administrator or Navigator Administrator. External authentication enables you to assign Cloudera Navigator user roles to LDAP or Active Directory groups to which the appropriate users belong.

For more information about Cloudera Manager user accounts, see Cloudera Manager User Accounts. For more information about Cloudera Navigator user roles, see Cloudera Navigator Data Management Component User Roles.

The following sections describe how to configure the supported external directory services.

Configuring Cloudera Navigator Authentication Using Active Directory

To configure Cloudera Navigator to use AD authentication:

  1. Select Clusters > Cloudera Management Service.
  2. Click the Configuration tab.
  3. Select Scope > Navigator Metadata Server.
  4. Select Category > External Authentication.
  5. In the Authentication Backend Order field, select the order in which Cloudera Navigator should attempt its authentication. You can choose to authenticate users using just one of the methods (using Cloudera Manager user accounts is the default), or you can set it so that if the user cannot be authenticated by the first method, it will attempt using the second method.
  6. In the External Authentication Type property, select Active Directory.
  7. In the LDAP URL property, provide the URL of the LDAP/Active Directory server to authenticate against. The URL has the form: [ldap|ldaps]://hostname:port. If a port is not specified, the default LDAP port is used (389 for LDAP and 636 for LDAPS). For more details on the LDAP URL format, see RFC 2255 .
  8. For the Bind Distinguished Name property, you require the userPrincipalName (UPN) of the user to bind as. For example, if the UPN is sampleuser@EXAMPLE.COM, the Bind Distinguished Name provided can be either sampleuser or the complete UPN, sampleuser@EXAMPLE.COM. This is used to connect to Active Directory for searching groups and to get other user information.
  9. In the LDAP Bind Password, enter the password for the bind user entered above.
  10. In the Active Directory NT Domain property, provide the NT domain to authenticate against.
  11. Click Save Changes to commit the changes.
  12. After changing the configuration settings, restart the Navigator Metadata Service: click the Instances tab on the Cloudera Management Service page, check Navigator Metadata Service, and click Actions for Selected > Restart.

Configuring Cloudera Navigator Authentication Using an OpenLDAP-compatible Server

For an OpenLDAP-compatible directory, you have several options for searching for users and groups:
  • You can specify a single base Distinguished Name (DN) and then provide a "Distinguished Name Pattern" to use to match a specific user in the LDAP directory.
  • Search filter options let you search for a particular user based on somewhat broader search criteria – for example Cloudera Navigator users could be members of different groups or organizational units (OUs), so a single pattern does not find all those users. Search filter options also let you find all the groups to which a user belongs, to help determine if that user should be allowed to log in.
  1. Select Clusters > Cloudera Management Service.
  2. Click the Configuration tab.
  3. Select Scope > Navigator Metadata Server.
  4. Select Category > External Authentication.
  5. In the Authentication Backend Order field, select the order in which Cloudera Navigator should attempt its authentication. You can choose to authenticate users using just one of the methods (using Cloudera Manager user accounts is the default), or you can set it so that if the user cannot be authenticated by the first method, it will attempt using the second method.
  6. In the External Authentication Type, select LDAP.
  7. In the LDAP URL property, provide the URL of the LDAP server and (optionally) the base Distinguished Name (DN) (the search base) as part of the URL — for example ldap://ldap-server.corp.com/dc=corp,dc=com.
  8. In the LDAP Bind User Distinguished Name property, enter the user's sAMAcountName. This is used to connect to the LDAP server for searching groups and to get other user information.
  9. In the LDAP Bind Password property, enter the password for the bind user entered above.
  10. To use a single "Distinguished Name Pattern", provide a pattern in the LDAP Distinguished Name Pattern property.

    Use {0} in the pattern to indicate where the username should go. For example, to search for a distinguished name where the uid attribute is the username, you might provide a pattern similar to uid={0},ou=People,dc=corp,dc=com. Cloudera Navigator substitutes the name provided at login into this pattern and performs a search for that specific user. So if a user provides the username "foo" at the Cloudera Navigator login page, Cloudera Navigator will search for the DN uid=foo,ou=People,dc=corp,dc=com.

    If you provided a base DN along with the URL, the pattern only needs to specify the rest of the DN pattern. For example, if the URL you provide is ldap://ldap-server.corp.com/dc=corp,dc=com, and the pattern is uid={0},ou=People, then the search DN will be uid=foo,ou=People,dc=corp,dc=com.

  11. You can also search using User or Group search filters, using the LDAP User Search Base, LDAP User Search Filter, LDAP Group Search Base and LDAP Group Search Filter settings. These allow you to combine a base DN with a search filter to allow a greater range of search targets.

    For example, if you want to authenticate users who may be in one of multiple OUs, the search filter mechanism will allow this. You can specify the User Search Base DN as dc=corp,dc=com and the user search filter as uid={0}. Then Cloudera Navigator will search for the user anywhere in the tree starting from the Base DN. Suppose you have two OUs—ou=Engineering and ou=Operations—Cloudera Navigator will find User "foo" if it exists in either of these OUs, that is, uid=foo,ou=Engineering,dc=corp,dc=com or uid=foo,ou=Operations,dc=corp,dc=com.

    You can use a user search filter along with a DN pattern, so that the search filter provides a fallback if the DN pattern search fails.

    The Groups filters let you search to determine if a DN or username is a member of a target group. In this case, the filter you provide can be something like member={0} where {0} will be replaced with the DN of the user you are authenticating. For a filter requiring the username, {1} may be used, as memberUid={1}. This will return a list of groups to which the user belongs.

  12. Click Save Changes to commit the changes.
  13. After changing the configuration settings, restart the Navigator Metadata Service: click the Instances tab on the Cloudera Management Service page, check Navigator Metadata Service, and click Actions for Selected > Restart.

Configuring Cloudera Navigator to Use LDAPS

If the LDAP server certificate has been signed by a trusted Certificate Authority (that is, VeriSign, GeoTrust, and so on), steps 1 and 2 below may not be necessary.
  1. Copy the CA certificate file to the Cloudera Navigator Server host.
  2. Import the CA certificate(s) from the CA certificate file to the local truststore. The default truststore is located in the $JAVA_HOME/jre/lib/security/cacerts file. This contains the default CA information shipped with the JDK. Create an alternate default file called jssecacerts in the same location as the cacerts file. You can now safely append CA certificates for any private or public CAs not present in the default cacerts file, while keeping the original file intact.
    For our example, we will follow this recommendation by copying the default cacerts file into the new jssecacerts file, and then importing the CA certificate to this alternate truststore. 
    $ cp $JAVA_HOME/jre/lib/security/cacerts \
  $JAVA_HOME/jre/lib/jssecacerts
    $ /usr/java/latest/bin/keytool -import -alias nt_domain_name \
-keystore /usr/java/latest/jre/lib/security/jssecacerts -file path_to_cert
  3. Configure the LDAP URL property to use ldaps://ldap_server instead of ldap://ldap_server.

Configuring Cloudera Navigator Authentication Using SAML

Cloudera Navigator supports the Security Assertion Markup Language (SAML), an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider (IDP) and a service provider (SP). The SAML specification defines three roles: the principal (typically a user), the IDP, and the SP. In the use case addressed by SAML, the principal (user agent) requests a service from the service provider. The service provider requests and obtains an identity assertion from the IDP. On the basis of this assertion, the SP can make an access control decision—in other words it can decide whether to perform some service for the connected principal.

The primary SAML use case is called web browser single sign-on (SSO). A user wielding a user agent (usually a web browser) requests a web resource protected by a SAML SP. The SP, wanting to know the identity of the requesting user, issues an authentication request to a SAML IDP through the user agent. In the context of this terminology, Cloudera Navigator operates as a SP. This topic discusses the Cloudera Navigator part of the configuration process; it assumes that you are familiar with SAML and SAML configuration in a general sense, and that you have a functioning IDP already deployed.

Setting up Cloudera Navigator to use SAML requires the following steps.

  1. Preparing Files
  2. Configuring Cloudera Navigator
  3. Configuring the IDP
  4. Verifying Authentication and Authorization

Preparing Files

You will need to prepare the following files and information, and provide these to Cloudera Navigator:
  • A Java keystore containing a private key for Cloudera Navigator to use to sign/encrypt SAML messages.
  • The SAML metadata XML file from your IDP. This file must contain the public certificates needed to verify the sign/encrypt key used by your IDP per the SAML Metadata Interoperability Profile.
  • The entity ID that should be used to identify the Navigator Metadata Server instance.
  • How the user ID is passed in the SAML authentication response:
    • As an attribute. If so, what identifier is used.
    • As the NameID.
  • The method by which the Cloudera Navigator role will be established:
    • From an attribute in the authentication response:
      • What identifier will be used for the attribute
      • What values will be passed to indicate each role
    • From an external script that will be called for each use:
      • The script takes user ID as $1
      • The script must assign an exit code to reflect successful authentication of the assigned role:
        • 0 - Full Administrator
        • 1 - User Administrator
        • 2 - Auditing Viewer
        • 4 - Lineage Viewer
        • 8 - Metadata Administrator
        • 16 - Policy Viewer
        • 32 - Policy Administrator
        • 64 - Custom Metadata Administrator
        • A negative value is returned for a failure to authenticate
        To assign more than one role, add the numbers for the roles. For example, to assign the Policy Viewer and User Administrator roles, the exit code should be 17.

Configuring Cloudera Navigator

  1. Select Clusters > Cloudera Management Service.
  2. Click the Configuration tab.
  3. Select Scope > Navigator Metadata Server.
  4. Select Category > External Authentication.
  5. Type SAML in the Search box.
  6. Set the External Authentication Type property to SAML (the Authentication Backend Order property is ignored for SAML).
  7. Set the Path to SAML IDP Metadata File property to point to the IDP metadata file.
  8. Set the Path to SAML Keystore File property to point to the Java keystore file containing the Cloudera Navigator private key (prepared above).
  9. In the SAML Keystore Password property, set the SAML keystore password.
  10. In the Alias of SAML Sign/Encrypt Private Key property, set the alias used to identify the private key for Cloudera Navigator to use.
  11. In the SAML Sign/Encrypt Private Key Password property, set the password for the sign/encrypt private key.
  12. Set the SAML Entity ID property if:
    • There is more than one Cloudera Navigator instance being used with the same IDP (each instance needs a different entity ID).
    • Entity IDs are assigned by organizational policy.
    The entity ID value should be unique to the current Navigator Metadata Server installation.
  13. In the Source of User ID in SAML Response property, set whether the user ID will be obtained from an attribute or the NameID.

    If an attribute will be used, set the attribute name in the SAML Attribute Identifier for User ID property. The default value is the normal OID used for user IDs and so may not need to be changed.

  14. In the SAML Role Assignment Mechanism property, set whether the role assignment will be done from an attribute or an external script.
    • If an attribute will be used:
      • In the SAML Attribute Identifier for User Role property, set the attribute name if necessary. The default value is the normal OID used for OrganizationalUnits and so may not need to be changed.
      • In the SAML Attribute Values for Roles property, set which attribute values will be used to indicate the user role.
    • If an external script will be used, set the path to that script in the Path to SAML Role Assignment Script property. Make sure that the script is executable (an executable binary is fine - it doesn’t need to be a shell script).
  15. Click Save Changes to commit the changes.
  16. Restart the Navigator Metadata Server role.

Configuring the IDP

After the Cloudera Navigator is restarted, it will attempt to redirect to the IDP login page instead of showing the normal Cloudera Navigator login page. This may or may not succeed, depending on how the IDP is configured. In either case, the IDP will need to be configured to recognize Cloudera Navigator before authentication will actually succeed. The details of this process are specific to each IDP implementation - refer to your IDP documentation for details.
  1. Download Cloudera Navigator's SAML metadata XML file from http://hostname:7187/saml/metadata.
  2. Inspect the metadata file and ensure that any URLs contained in the file can be resolved by users’ web browsers. The IDP will redirect web browsers to these URLs at various points in the process. If the browser cannot resolve them, authentication will fail. If the URLs are incorrect, you can manually fix the XML file or set the SAML Entity Base URL property in the Navigator Metadata Server configuration to the right value, and then re-download the file.
  3. Provide this metadata file to your IDP using whatever mechanism your IDP provides.
  4. Ensure that the IDP has access to whatever public certificates are necessary to validate the private key that was provided by Cloudera Navigator earlier.
  5. Ensure that the IDP is configured to provide the User ID and Role using the attribute names that Cloudera Navigator was configured to expect, if relevant.
  6. Ensure the changes to the IDP configuration have taken effect (a restart may be necessary).

Verifying Authentication and Authorization

  1. Return to the Cloudera Navigator home page at: http://hostname:7187/.
  2. Attempt to log in with credentials for a user that is entitled. The authentication should complete and you should see the Home page.
  3. If authentication fails, you will see an IDP provided error message. Cloudera Navigator is not involved in this part of the process, and you must ensure the IDP is working correctly to complete the authentication.
  4. If authentication succeeds but the user is not authorized to use Cloudera Navigator, they will be taken to an error page that explains the situation. If a user who should be authorized sees this error, then you will need to verify their role configuration, and ensure that it is being properly communicated to the Navigator Metadata Server, whether by attribute or external script. The Cloudera Navigator log will provide details on failures to establish a user’s role. If any errors occur during role mapping, Cloudera Navigator will assume the user is unauthorized.

Bypassing SAML SSO

As of Cloudera Manager 5.10.2 (Navigator 2.9.2), you can bypass SAML SSO by directly accessing the Cloudera Navigator login page at http://hostname:7187/locallogin.html. You can turn off this bypass by setting the Skip Authorization Check property (nav.auth.skip_saml_auth_check) in the Navigator Metadata Server Advanced Configuration Snippet (Safety Valve) for cloudera-navigator.properties .