[
https://issues.apache.org/jira/browse/HADOOP-15518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504999#comment-16504999
]
Eric Yang commented on HADOOP-15518:
------------------------------------
[~lmccay] {quote}it is unclear to me where the race condition is. My assumption
is that the filters are invoked linearly so a second filter shouldn't be
invoked until the request state is set properly.{quote}
Your assumption is correct, and the diagram might help to explain the race
conditions.
HIgh level of the sequence of events of a normal setup:
| Time | Browser | HttpRequest | HttpResponse |
| 1 | Send WWW-Authenticate 1 | | |
| 2 | | AuthenticationFilter checks WWW-Authenticate 1 | |
| 3 | | Call authenticate to verify WWW-Authenticate 1 ticket with KDC | |
| 4 | | Set User principal and remote user via Java security callbacks | |
| 5 | | | AuthenticationFilter writes WWW-Authenticate 2 |
| 6 | | | Business logic |
| 7 | Received WWW-Authenticate 2 | | |
Events of duplicated AuthenticationFilters are:
| Time | Browser | HttpRequest | HttpResponse |
| 1 | WWW-Authenticate 1 | | |
| 2 | | AuthenticationFilter Instance 1 Check WWW-Authenticate 1 | |
| 3 | | Call authenticate to verify WWW-Authenticate 1 ticket with KDC | |
| 4 | | Set User principal and remote user via Java security callbacks | |
| 5 | | | AuthenticationFilter Instance 1 writes WWW-Authenticate 2 |
| 6 | | AuthenticationFilter Instance 2 Check WWW-Autnenticate 1 |
AuthenticationFilter Instance 2 rewrites HTTP status with 403 |
Browser has never retrieved WWW-Authenticate 2 header from server because
HttpResponse is still buffered on server side. The race condition is between
HttpRequest at time 6 is still using existing ticket 1 without using the new
ticket 2 that is issued at time 5. Second Filter is invoked at time 6 using
out dated data.
> Authentication filter calling handler after request already authenticated
> -------------------------------------------------------------------------
>
> Key: HADOOP-15518
> URL: https://issues.apache.org/jira/browse/HADOOP-15518
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.7.1
> Reporter: Kevin Minder
> Assignee: Kevin Minder
> Priority: Major
> Attachments: HADOOP-15518-001.patch
>
>
> The hadoop-auth AuthenticationFilter will invoke its handler even if a prior
> successful authentication has occurred in the current request. This
> primarily affects situations where multiple authentication mechanism has been
> configured. For example when core-site.xml's has
> hadoop.http.authentication.type=kerberos and yarn-site.xml has
> yarn.timeline-service.http-authentication.type=kerberos the result is an
> attempt to perform two Kerberos authentications for the same request. This
> in turn results in Kerberos triggering a replay attack detection. The
> javadocs for AuthenticationHandler
> ([https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java)]
> indicate for the authenticate method that
> {quote}This method is invoked by the AuthenticationFilter only if the HTTP
> client request is not yet authenticated.
> {quote}
> This does not appear to be the case in practice.
> I've create a patch and tested on a limited number of functional use cases
> (e.g. the timeline-service issue noted above). If there is general agreement
> that the change is valid I'll add unit tests to the patch.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
