User Authentication

Each user has a unique username and password that must be provided in order to log in. Authentication is the process by which the user-supplied username and password are matched against the list of authorized users to determine whether to grant access (stored either in the local user database server or in the remote LDAP/Active Directory server). Authentication is the process that determines what exact access to allow, in terms of the specific roles granted to that user.

User authentication information is stored on a secure server. Users can be authenticated using any of the following methods:

  • An internal user database.
  • One or more existing LDAP or Active Directory servers that you can connect to using Direct Bind or Search Bind. The following configurations are supported when using multiple LDAP/AD servers:
    • Servers located across multiple domains. In this case, a user may specify the domain to use when accessing the web interface, as described in Launching and Logging In.
    • Multiple servers in the same domain. This allows authentication to occur in a failover mode when one or more of the servers is down or otherwise unreachable.
    • Both of the above. In this case, multiple LDAP/AD domains can be used where one or more of those domains includes multiple servers set up to allow failover.

HPE Ezmeral Runtime Enterprise can also apply user authentication settings as follows:

  • Platform: The same authentication settings apply to every tenant/project. HPE Ezmeral Runtime Enterprise may be configured to use local authentication or one or more LDAP/AD domains. Further, each domain may be configured to use multiple servers in order to provide failover protection.

Non-SSO Access

The non-SSO user authentication process is identical when using either the internal user database or an external LDAP/AD server:

  1. A user accesses the Login screen using a Web browser.
    • If tenant-independent authentication is not enabled, the URL will be http://<ip_address>, where <ip_address> is either:
      • The IP address of the Controller host (if platform HA is not enabled).
      • The cluster IP address (if platform HA is enabled and you provide a cluster IP address).
      • The IP address of a Gateway host (if platform HA is enabled but no cluster IP address is provided). When using a private (non-routable) virtual node network, the Primary Controller and Shadow Controller need not be on the same subnet unless a Cluster IP address is specified.
      • Hostname of the Controller host.
      • A DNS-mapped URL.
    NOTE Replace http with https if a secure connection is required.
  2. The user enters her or his username and password in the appropriate fields and attempts to login. If multiple LDAP/AD domains are configured, then the user must either specify the domain to use via the Domain for Authentication pull-down menu or enter their username as user@domain. See Launching and Logging In.
  3. The user-supplied username and password is securely to the authentication server, if TLS is enabled.
  4. The authentication server returns a response that indicates either a valid (allow user to login) or invalid (prevent user from logging in) login attempt.
  5. If the login attempt is valid, then the user will be matched with the roles granted to that user and allowed the proper access.

Using the internal user database is fast and convenient from an IT perspective. However, it may complicate user administration for various reasons, such as:

  • The user may be required to change their password on the rest of the network but this change will not be reflected in HPE Ezmeral Runtime Enterprise.
  • A user who is removed from the network (such as when they leave the organization) must be independently removed from the HPE Ezmeral Runtime Enterprise user database.

Connecting to your existing user authentication server requires you to supply some information about that server during installation. Contact your user administrator for the following information:

  • LDAP: LDAP Host, User Attribute, User Subtree DN
  • Active Directory: AD Host, User Attribute, User Subtree DN

SSO Access

Single Sign On (SSO) allows users to supply login credentials once, and then gain access to all authorized resources and applications without having to log in to each application separately. When SSO is configured, authorized users will proceed directly to the Dashboard screen without having to log in, by navigating to either of the following, as appropriate:

  • http://<ip_address>, if tenant independent authentication is not enabled.

SSO configuration requires both of the following, which you specify in the User Authentication tab of the System Settings screen, or the External Authentication tab of the Create Tenant or the Edit Tenant screen. See Configuring User Authentication Settings:

  • A metadata XML file that is provided by the Identity Provider (IdP)
  • Configuring the XPath parameter to refer to a location in the SAML Response that contains the LDAP/AD username of the authenticated user. This will commonly be //saml:Subject/saml:NameID/text(), but this value may be passed in the SAML Attributes as well. In that case, the XPath may be similar to the following:

You can then use LDAP/AD groups to assign roles to users. See Assigning/Revoking User Roles (LDAP/AD). Groups can also be assigned to users from the SAML Assertion. In order to point to the group field in the SAML Assertion, fill in the Group XPath field. This value will probably be similar to //saml:AttributeStatement/saml:Attribute[@Name="Groups"]/sam l:AttributeValue/text(). If all of the groups are included in a single XML node with a separator character, then the Group Separator can be used to specify the character that separates the groups. A user will not receive groups from two different sources; they will only receive groups from one of the following:

  • The SAML Assertion
  • The LDAP/AD server

If platform High Availability is not enabled, then the hostname of the Controller host must be mapped to the IP address of the Controller host via a DNS server that can be accessed by the user. This allows a user-initiated browser GET request to correctly resolve to the Controller host. For deployments where platform HA is enabled, this will be a hostname that resolves to the cluster IP address.

The IdP must be configured with the following information:

  • Audience: This field is not required; however, providing the base URL of the SAML server is more secure than a blank entry. If you do enter a URL, then this URL must exactly match the SAML Application Name that you will specify in HPE Ezmeral Runtime Enterprise.
  • Recipient: [<hostname>|<ip_address>]/bdswebui/login, where <hostname> is the name of the Controller host, the HA cluster, or the Controller gageway FDQN as appropriate, and <ip_address> is the Controller, cluster IP address, or Gateway host IP address.

    For HPE Ezmeral Runtime Enterprise 5.3.5 and later releases, to use SAML SSO with Jupyterhub Notebooks, you must specify the Controller gateway FDQN for <hostname>. Do not specify an IP address.

    Use either a hostname or an IP address, but not both. For example, controllername/bdswebui/login or

  • Consumer URL Validator: Enter <platform_info>/bdswebui/login/, where <platform_info> is one of the following:
    • .* - This is a valid generic entry, but is less secure. For example, .*/bdswebui/login/.
    • <name-or-ip>, which will be either the FQDN or IP address of either the Controller host or HA cluster, as described above. This entry is more secure than the generic entry. For example, or
  • Consumer URL: <platform_info>/bdswebui/saml_login/, where <platform_info> is either a generic or specific entry, as described above.
  • Further, the IdP must send the user's LDAP/AD username in the body of the SAML assertion, either as the subject or as a field in the SAML attributes.

The IdP will provide a SAML IdP XML metadata file that you will use when configuring HPE Ezmeral Runtime Enterprise for SSO.