Authentication in Data Fabric

Describes types of authentication available with the HPE Ezmeral Data Fabric and how to manage user authentication with the maprlogin utility.

Authentication ensures that who you really are and who you claim to be, match when identifying the end user to the system. data-fabric authentication supports standard Basic Authentication and SPNEGO authentication for web-based interfaces, and supports data-fabric tickets for many of the core system component non-web-based interfaces. A ticket is an object that contains specific information about a user, an expiration time, and a key. Tickets uniquely identify a user and are encrypted to protect their contents. You can use tickets to establish sessions between a user and the cluster.

Types of Authentication in Data Fabric

Data Fabric supports two methods of authenticating a user and generating a ticket: a username-password pair and Kerberos. Both of these methods are mediated by the maprlogin utility. When you authenticate with a username-password pair, the system verifies your credentials using Pluggable Authentication Modules (PAM). You can configure the cluster to use any registry that has a PAM module.

Data Fabric tickets contain the following information:

  • UID (generated from the UNIX user ID)
  • GIDs (group IDs for each group the user belongs to)
  • Ticket creation time
  • Ticket expiration time (by default, 14 days)
  • Renewal expiration time (by default, 30 days from the date of ticket creation)

A data-fabric ticket determines the user's identity. The system uses the ticket as the basis for authorization. A data-fabric cluster with security features enabled does not rely on the client-side operating system identity.

The maprlogin Utility for Generating Tickets

The maprlogin utility supports user authentication with either username and password, or Kerberos to generate a unique session token called a ticket. The following diagram outlines the process flow:



Data Fabric tickets are either implicitly or explicitly generated. On clusters that use Kerberos for authentication, a user that runs a data-fabric command without first using the maprlogin utility implicitly obtains a data-fabric ticket. During usage, the client runtime process first checks for a valid user ticket, and uses that ticket if it exists. If a ticket does not exist, the runtime process checks if Kerberos is enabled for the cluster and then checks for an existing valid Kerberos identity. When a valid Kerberos identity is found, the client implicitly generates a ticket for that Kerberos identity.

When you explicitly generate a ticket, you can authenticate either with your username and password, or with Kerberos:

  1. The user on the client machine invokes the maprlogin utility, which connects to a CLDB node in the cluster using HTTPS. The host name for the CLDB node is specified in the mapr-clusters.conf file.
    • For username-password authentication, the node authenticates using PAM modules with the Java Authentication and Authorization Service (JAAS).

      The JAAS configuration is specified in the mapr.login.conf file. The system can use any registry that has a PAM module available.

    • For Kerberos authentication, the CLDB node verifies the Kerberos principal with the keytab file.
  2. After authenticating, the CLDB node uses the standard UNIX APIs getpwnam_r and getgrouplist, which are controlled by the /etc/nsswitch.conf file, to determine the user IDs and group IDs.
  3. The CLDB node generates a ticket and returns it to the client machine, completing the login communication between the client and the CLDB.
  4. After login, the data-fabric server validates that the ticket is properly encrypted, to verify that the ticket was issued by the cluster's CLDB.
  5. The server also verifies that the ticket has not expired or been included in denylist.
  6. The server checks the ticket for a privileged identity such as the mapr user.

    Privileged identities have impersonation functionality enabled.

  7. The ticket's user and group information are used for authorization to the cluster, unless impersonation is in effect.