[ 
https://issues.apache.org/jira/browse/AMBARI-18406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15510909#comment-15510909
 ] 

Hudson commented on AMBARI-18406:
---------------------------------

FAILURE: Integrated in Jenkins build Ambari-branch-2.5 #68 (See 
[https://builds.apache.org/job/Ambari-branch-2.5/68/])
AMBARI-18406. Create authentication filter to perform Kerberos (rlevas: 
[http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=39b75711bd49bf8c51a01026e65546bd288ab45a])
* (edit) 
ambari-server/src/test/java/org/apache/ambari/server/security/authentication/kerberos/AmbariAuthToLocalUserDetailsServiceTest.java


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



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

Reply via email to