Fallthrough authentication

Normally, if a user fails to authenticate with the first chosen authentication record, the user is rejected.

Normally, if a user fails to authenticate with the first chosen authentication record, the user is rejected. However, certain authentication methods can be specified to instead, upon failure, "fall through" to an authentication record with a lower priority. This can be useful, for example, for using multiple LDAP search attributes.

Authentication fallthrough is disabled by default for new records.

Another way to bypass method priority or implement fallthrough authentication is to implement it on the client instead. For details, see Authentication filtering.

Authentication method compatibility

The following table shows each authentication method's compatibility with fallthrough authentication. A value of "yes" indicates that the method in the column can fall through and validate the row method it falls through to. A value of "no" indicates that you cannot fall through to it and authentication ends.

A value of "-" (dash) indicates that while fallthrough works, it has no meaningful effect. For example, a hash authentication record can fall through to another hash authentication record, but authentication will always fail because you cannot fall through to a correct password:

Column falls through to row	ldap	hash	tls	ident	oauth	gss	trust	reject
ldap	yes	yes	yes	yes	no	no	no	no
hash	yes	-	yes	yes	no	no	no	no
tls	yes	yes	-	yes	no	no	no	no
ident	yes	yes	yes	yes	no	no	no	no
oauth	no	no	no	no	no	no	no	no
gss	no	no	no	no	no	no	no	no
trust	yes	yes	yes	yes	no	no	no	no
reject	yes	yes	yes	yes	no	no	no	no

For example, suppose the user Bob was granted the following authentication record with fallthrough enabled:

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0' FALLTHROUGH;

In addition, Bob has the public role, and therefore has the default authentication records:

=> SELECT auth_name,is_auth_enabled,auth_host_type,auth_method,auth_priority,is_fallthrough_enabled FROM client_auth;
         auth_name         | is_auth_enabled | auth_host_type | auth_method | auth_priority | is_fallthrough_enabled
---------------------------+-----------------+----------------+-------------+---------------+------------------------
 default_hash_network_ipv4 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_network_ipv6 | True            | HOST           | PASSWORD    |            -1 | False
 default_hash_local        | True            | LOCAL          | PASSWORD    |            -1 | False
(3 rows)

If Bob, connecting from a remote address, fails to authenticate with v_tls_auth, Vertica attempts to authenticate him with the next (in order of priority) authentication record, default_hash_network_ipv4.

Logging authentication failures

Login failures are only logged if the user is rejected after all granted authentication records have failed. Only the final failure is logged.

For example, suppose a user is granted both tls and password authentication records, and the tls record falls through to the password record.

If the user fails to authenticate with both the tls record and the password record, then only the password failure is logged in LOGIN_FAILURES.

However, if the user fails to authenticate with the tls record, but succeeds with the password record, then no failure is logged in LOGIN_FAILURES because the user was not rejected at the end of the record chain.

Examples

To enable fallthrough on a new authentication record, use CREATE AUTHENTICATION:

=> CREATE AUTHENTICATION v_tls_auth METHOD 'tls' HOST TLS '0.0.0.0/0' FALLTHROUGH;

To toggle fallthrough on an existing authentication record, use ALTER AUTHENTICATION:

=> ALTER AUTHENTICATION v_tls_auth NO FALLTHROUGH; -- disable
=> ALTER AUTHENTICATION v_tls_auth FALLTHROUGH; -- enable