[ 
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.






  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-Authentication-Type" with the value of "kerberos":

{noformat}
X-Authentication-Type: kerberos
{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
>
>
> 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.



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

Reply via email to