ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Levas (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-18406) Create authentication filter to perform Kerberos authentication for Ambari
Date Fri, 07 Oct 2016 15:27:20 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Levas updated AMBARI-18406:
----------------------------------
    Description: 
Users should be able to authenticate to use Ambari by providing a Kerberos token using SPNEGO
- Simple and Protected GSSAPI Negotiation Mechanism.  This includes access to the Ambari REST
API as well as the Ambari web-based UI. 

The implementation should support the ability to perform the full SPNEGO handshake as well
as access requests directly providing the appropriate HTTP header containing the Kerberos
token. For example:

{noformat}
Authorization: Negotiate YIICcgY...r/vJcLO
{noformat}

In the full handshake model
# The client requests access to a web resource
# The server responds with an HTTP 401 status ({{Unauthorized}}), including the header {{WWW-Authenticate:
Negotiate}}
# The client generates the Kerberos data and creates a new request containing the authentication
header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}

Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}}) when authentication
is needed, a _hint_ must be sent along with the request indicate to Ambari that Kerberos authentication
is desired.  If this _hint_ is received, then Ambari will respond with the appropriate status
and header to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header named
"X-Negotiate-Authentication" with the value of "true":

{noformat}
X-Negotiate-Authentication: true
{noformat}

No matter what the handshake mechanism is (or lack of), once the Kerberos token is received
by Ambari, Ambari is to parse and validate the token.  If a failure occurs, Ambari is to respond
with the appropriate HTTP status and related header(s).  Upon success, the user's principal
name is retrieved and converted into a _local_ user name.  The use of an auth-to-local rule
set processor may be needed to perform this translation.  Using this _local_ username, an
appropriate Ambari user account is located and used as the authenticated users identity -
details, privileges, etc.... Failure to find an appropriate Ambari user account is to result
in an authentication failure response.

*To enable this feature*, the following properties may be set in {{ambari.properties}}:

{{authentication.kerberos.enabled}} - Determines whether to use Kerberos (SPNEGO) authentication
when connecting Ambari.
* {{true}} - enables this feature
* {{false}} - disables this feature (default)

{{authentication.kerberos.spnego.principal}} - The Kerberos principal name to use when verifying
user-supplied Kerberos tokens for authentication via SPNEGO.
* HTTP/_HOST  (default)

authentication.kerberos.spnego.keytab.file - The Kerberos keytab file to use when verifying
user-supplied Kerberos tokens for authentication via SPNEGO.
*  /etc/security/keytabs/spnego.service.keytab (default)

{{authentication.kerberos.user.types}} - A comma-delimited (ordered) list of preferred user
types to use when finding the Ambari user account for the user-supplied Kerberos identity
during authentication via SPNEGO.
* LDAP (default)

{{authentication.kerberos.auth_to_local.rules}} - The auth-to-local rules set to use when
translating a user's principal name to a local user name during authentication via SPNEGO.
* DEFAULT (default)
* Rules are to be separated by "/n":
{noformat}
authentication.kerberos.auth_to_local.rules=RULE:[1:$1@$0](ambari-server-c1@EXAMPLE.COM)s/.*/admin/\nDEFAULT
{noformat}





  was:
Users should be able to authenticate to use Ambari by providing a Kerberos token using SPNEGO
- Simple and Protected GSSAPI Negotiation Mechanism.  This includes access to the Ambari REST
API as well as the Ambari web-based UI. 

The implementation should support the ability to perform the full SPNEGO handshake as well
as access requests directly providing the appropriate HTTP header containing the Kerberos
token. For example:

{noformat}
Authorization: Negotiate YIICcgY...r/vJcLO
{noformat}

In the full handshake model
# The client requests access to a web resource
# The server responds with an HTTP 401 status ({{Unauthorized}}), including the header {{WWW-Authenticate:
Negotiate}}
# The client generates the Kerberos data and creates a new request containing the authentication
header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}

Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}}) when authentication
is needed, a _hint_ must be sent along with the request indicate to Ambari that Kerberos authentication
is desired.  If this _hint_ is received, then Ambari will respond with the appropriate status
and header to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header named
"X-Negotiate-Authentication" with the value of "true":

{noformat}
X-Negotiate-Authentication: true
{noformat}

No matter what the handshake mechanism is (or lack of), once the Kerberos token is received
by Ambari, Ambari is to parse and validate the token.  If a failure occurs, Ambari is to respond
with the appropriate HTTP status and related header(s).  Upon success, the user's principal
name is retrieved and converted into a _local_ user name.  The use of an auth-to-local rule
set processor may be needed to perform this translation.  Using this _local_ username, an
appropriate Ambari user account is located and used as the authenticated users identity -
details, privileges, etc.... Failure to find an appropriate Ambari user account is to result
in an authentication failure response.







> Create authentication filter to perform Kerberos authentication for Ambari
> --------------------------------------------------------------------------
>
>                 Key: AMBARI-18406
>                 URL: https://issues.apache.org/jira/browse/AMBARI-18406
>             Project: Ambari
>          Issue Type: Task
>          Components: ambari-server
>    Affects Versions: 2.5.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>              Labels: authentication, kerberos, security
>             Fix For: 2.5.0
>
>         Attachments: AMBARI-18406_branch-2.5_01.patch, AMBARI-18406_branch-2.5_02.patch,
AMBARI-18406_branch-2.5_03.patch, AMBARI-18406_branch-2.5_03_amended.patch, AMBARI-18406_trunk_01.patch,
AMBARI-18406_trunk_02.patch, AMBARI-18406_trunk_03.patch, AMBARI-18406_trunk_03_amended.patch
>
>
> Users should be able to authenticate to use Ambari by providing a Kerberos token using
SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism.  This includes access to the Ambari
REST API as well as the Ambari web-based UI. 
> The implementation should support the ability to perform the full SPNEGO handshake as
well as access requests directly providing the appropriate HTTP header containing the Kerberos
token. For example:
> {noformat}
> Authorization: Negotiate YIICcgY...r/vJcLO
> {noformat}
> In the full handshake model
> # The client requests access to a web resource
> # The server responds with an HTTP 401 status ({{Unauthorized}}), including the header
{{WWW-Authenticate: Negotiate}}
> # The client generates the Kerberos data and creates a new request containing the authentication
header - {{Authorization: Negotiate YIICcgY...r/vJcLO}}
> Since Ambari needs to generally return a HTTP status of 403 ({{Forbidden}}) when authentication
is needed, a _hint_ must be sent along with the request indicate to Ambari that Kerberos authentication
is desired.  If this _hint_ is received, then Ambari will respond with the appropriate status
and header to initiate SPNEGO with the client. This _hint_ is an Ambari-specific header named
"X-Negotiate-Authentication" with the value of "true":
> {noformat}
> X-Negotiate-Authentication: true
> {noformat}
> No matter what the handshake mechanism is (or lack of), once the Kerberos token is received
by Ambari, Ambari is to parse and validate the token.  If a failure occurs, Ambari is to respond
with the appropriate HTTP status and related header(s).  Upon success, the user's principal
name is retrieved and converted into a _local_ user name.  The use of an auth-to-local rule
set processor may be needed to perform this translation.  Using this _local_ username, an
appropriate Ambari user account is located and used as the authenticated users identity -
details, privileges, etc.... Failure to find an appropriate Ambari user account is to result
in an authentication failure response.
> *To enable this feature*, the following properties may be set in {{ambari.properties}}:
> {{authentication.kerberos.enabled}} - Determines whether to use Kerberos (SPNEGO) authentication
when connecting Ambari.
> * {{true}} - enables this feature
> * {{false}} - disables this feature (default)
> {{authentication.kerberos.spnego.principal}} - The Kerberos principal name to use when
verifying user-supplied Kerberos tokens for authentication via SPNEGO.
> * HTTP/_HOST  (default)
> authentication.kerberos.spnego.keytab.file - The Kerberos keytab file to use when verifying
user-supplied Kerberos tokens for authentication via SPNEGO.
> *  /etc/security/keytabs/spnego.service.keytab (default)
> {{authentication.kerberos.user.types}} - A comma-delimited (ordered) list of preferred
user types to use when finding the Ambari user account for the user-supplied Kerberos identity
during authentication via SPNEGO.
> * LDAP (default)
> {{authentication.kerberos.auth_to_local.rules}} - The auth-to-local rules set to use
when translating a user's principal name to a local user name during authentication via SPNEGO.
> * DEFAULT (default)
> * Rules are to be separated by "/n":
> {noformat}
> authentication.kerberos.auth_to_local.rules=RULE:[1:$1@$0](ambari-server-c1@EXAMPLE.COM)s/.*/admin/\nDEFAULT
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message