Implementing Client Authentication

Vertica restricts which database users can connect through client authentication. The database server uses client authentication to establish the identity of the requesting client and determines whether that client is authorized to connect to the Vertica server using the supplied credentials.

When a user or client application attempts to connect to Vertica, they must supply a user name and password.

Vertica offers several client authentication methods. You can configure Vertica to require just a user name for connections, you likely require more secure means of authentication, such as a password at a minimum.

How Client Authentication Works

When connecting to a Vertica database, a user or client application must supply the name of a valid user account. In addition, the application usually includes a means of authentication, such as a password or security certificate.

There are two types of client authentication:

• LOCAL: Authenticating users or applications that are trying to connect from the same node that the database is running on.
• HOST: Authenticating users or applications that are trying to connect from a node that has a different IPv4 or IPv6 address than the database.

The DBADMIN user manages the client authentication information that the database uses to authenticate users.

Vertica takes the following steps to authenticate users:

1. When a user or application attempts to connect to a Vertica database, the system checks to see if the user is a DBADMIN user. If so, authentication occurs using the assigned authentication method, local trust or local hash authentication.

2. For non-DBADMIN users, the database checks to see if the user is associated with an authentication method through a GRANT statement. If so, the database allows the user to log in if they match the parameters required for that authentication method.

   For detailed information on how authentication priorities work, see Priorities for Client Authentication Methods.

   The DBADMIN user can grant an authentication method to users or user roles. The DBADMIN user can also create a default authentication method that Vertica uses when no authentication has been associated with a user or role.

3. If the user has not been granted an authentication method, the database checks to see if the DBADMIN has established a default authentication method.
4. If the DBADMIN has specified a default authentication method, the database authenticates the user using that default method.
5. If you have not specified a default authentication method, the database checks to see if the DBADMIN user has defined any authentication methods. If not, no authentication information exists in the database. However, if a password exists, the DBADMIN user can log in.
6. If authentication information exists, Vertica rejects the user request to connect to the database. The DBADMIN has not granted an authentication method for that user nor has the DBADMIN defined a default authentication method for all users ('public').
7. If no authentication records exist in the database, Vertica uses implicit trust/implicit password to authenticate the user.

The following image illustrates the steps involved in client authentication:

IPv4 and IPv6 for Client Authentication

Vertica supports clients using either the IPv4 or the IPv6 protocol to connect to the database server. Internal communication between database servers must consistently use one address family (IPv4 or IPv6). The client, however, can connect to the database from either type of IP address.

If the client will be connecting from either IPv4 or IPv6, you must create two authentication methods, one for each address. Any authentication method that uses HOST authentication requires an IP address.

For example, the first statement allows users to connect from any IPv4 address. The second statement allows users to connect from any IPv6 address:

=> CREATE AUTHENTICATION <name> METHOD 'gss' HOST '0.0.0.0/0'; --IPv4
=> CREATE AUTHENTICATION <name> METHOD 'gss' HOST '::/0'; --IPv6

If you are using a literal IPv6 address in a URL, you must enclose the IPv6 address in square brackets as shown in the following examples:

=> ALTER AUTHENTICATION Ldap SET host='ldap://[1dfa:2bfa:3:45:5:6:7:877]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[fdfb:dbfa:0:65::177]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[fdfb::177]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[::1]';
=> ALTER AUTHENTICATION Ldap SET host='ldap://[1dfa:2bfa:3:45:5:6:7:877]:5678';

If you are working with a multi-node cluster, any IP/netmask settings in (HOST, HOST TLS, HOST NO TLS) must match all nodes in the cluster. This setup allows the database owner to authenticate with and administer every node in the cluster. For example, specifying 10.10.0.8/30 allows a CIDR address range of 10.10.0.8–10.10.0.11.

For detailed information about IPv6 addresses, see RFC 1924 and RFC 2732.

Supported Client Authentication Methods

Vertica supports the following types of authentication to prove a client's identity.

• Trust: Authorizes any user that connects to the database using a valid user name. No password is required and authentication is not performed.
• Reject: Rejects the connection attempt when a user with an invalid user name attempts to connect to the database.
• Kerberos (GSS): Authorizes connecting to the database using a MIT Kerberos implementation. The KDC must support Kerberos 5 using GSS-API. This API also provides compatibility with non-MIT Kerberos implementations, such as Java and Windows clients.
• Hash: Sends the hashed (SHA-512 by default) password over the network. The server sends the client a user salt and session salt.
• LDAP: Works like password authentication except the LDAP method authenticates the client against a Lightweight Directory Access Protocol or Active Directory server.
• Ident: Authenticates the client against the username in an Ident server.
• TLS authentication: Authenticates the client using digital certificates that contain a public key.

Local and Host Authentication

You can define a client authentication method as:

• Local: Local connection to the database.
• Host: Remote connection to the database from different hosts, each with their own IPv4 or IPv6 address and host parameters. For more information see IPv4 and IPv6 for Client Authentication above.

Some authentication methods cannot be designated as local, as listed in this table:

Authentication for Chained Users and Roles

Vertica supports creating chained users and roles, where you can grant ROLE2 privileges to ROLE1. All users in ROLE1 use the same authentication assigned to ROLE2. For example:

=> CREATE USER user1;
=> CREATE ROLE role1;
=> CREATE ROLE role2;
=> CREATE AUTHENTICATION h1 method 'hash' local;
=> GRANT AUTHENTICATION h1 to role2;
=> GRANT role2 to role1;
=> GRANT role1 to user1;

The user and role chain in the example above can be illustrated as follows:

auth1 -> role2 -> role1 -> user1

In this example, since role2 privileges are granted to role1 you only need to grant authentication to role2 to also enable it for role1.