RANGER-5499: Add support for header based authentication

[kumaab]

What changes were proposed in this pull request?

Ranger servers currently support multiple authentication mechanisms, including Kerberos, username/password (LDAP, local users), JWT, SSO. To support deployments behind proxy servers that handle authentication, Ranger servers should support header based authentication. When this authentication is enabled, Ranger should look for configured HTTP headers to find the username and request-id.

How was this patch tested?

Pending CI

[mneethiraj]

authType and authMechanism seem to capture the same details. For example, given a authMechanism can there be different authType values or vice-versa? If not, I suggest dropping authMechanism (and the enum) from here.

[kumaab]

Different authMechanism's can map to the sameauthType. for ex: both HEADER and KERBEROS authMechanism map to AUTH_TYPE_TRUSTED_PROXY authType. AuthMechanism can have more enum values once the existing filters migrate to use RangerAuthenticationToken.

[mneethiraj]

Mapping for authMechanisms HEADER and KERBEROS to AUTH_TYPE_TRUSTED_PROXY doesn't seem correct. Consider the following mappings:

• BASIC => XXAuthSession.AUTH_TYPE_PASSWORD
• KERBEROS =>XXAuthSession.AUTH_TYPE_KERBEROS
• SSO => XXAuthSession.AUTH_TYPE_SSO
• HEADER => XXAuthSession.AUTH_TYPE_TRUSTED_PROXY

[mneethiraj]

Why is it necessary to capture requestId in RangerAuthenticationToken? I sugest dropping it.

[kumaab]

It's used in the last filter RangerSecurityContextFormationFilter:

String requestId = (auth instanceof RangerAuthenticationToken) ? ((RangerAuthenticationToken) auth).getRequestId() : null;

[mneethiraj]

requestId shouldn't be tied to a session; instead it should be read from each request header.