[
https://issues.apache.org/jira/browse/OOZIE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Kanter updated OOZIE-2485:
---------------------------------
Attachment: OOZIE-2485.001.patch
Before I explain what the patch does, here’s what the code is currently doing
(which was’t super-obvious to me at first):
# Read in the cached token, if enabled
# If we have a token, make a connection to the server to test if the token is
still valid (i.e. hasn’t expired or been tampered with)
#- If it’s not valid, then let’s delete it
# If we don’t have a token (or it was deleted in the previous step), get a new
one from the Server using Kerberos or Pseudo auth (which uses a new connection
under the covers)
# If we now have a new token, write it to the cache file (if enabled)
# Create a new connection using the token and return it up to the caller, which
may further modify it and then use it
As you can see, we may make 2-3 connections per REST call. This is partly due
to how the code is setup where the auth client code passes the connection to
other code, which doesn’t know about auth. While that could be changed, it
would require a lot of refactoring and changing how the OozieClient and
AuthOozieClient are setup.
The main new thing is the else statement with the big comment. Most of the
other stuff is some minor refactoring, some helpful comments, and an
optimization that also prevents a rare race condition. Here’s a summary of
what I changed:
- We can save a call to the server by parsing and checking the expiration time
of the token locally. If it’s expired, we can just delete it. I also have it
consider -5 minutes as expired to prevent a race condition (though I haven’t
seen this ever occur) where an almost expiring token would pass the server
check but fail by the time the actual command is made. Given that this should
happen quickly, I haven’t seen this problem before, but 5 min seems like more
than a safe buffer.
- One of the changes made by HADOOP-10301 is that PseudoAuthenticationHandler
will now return a 403 instead of a 401 when the token is invalid. The patch
now checks for both 401 and 403 to handle either code
- The other change made by HADOOP-10301 is that KerberosAuthenticationHandler
will now return a 200 instead of a 401 when the token is invalid, plus, it will
give you a new token. The patch now tries to extract the token, if it’s there,
in this case. I added a big comment explaining this.
- I replaced
{code:java}
new AuthenticatedURL(authenticator).openConnection(url, currentToken);
{code}
with
{code}
authenticator.authenticate(url, currentToken);
{code}
because it’s more clear and saves creating an unused connection. If you look
at the AuthenticatedURL code, it just calls authenticate and then creates a new
connection that we’re not using here.
I think checking the expiration time locally should only be a problem if the
local clock is way off (in which case other things like Kerberos won’t work
anyway). If the clock is wrong, either it won’t delete the token in which case
the check to the server will take care of it, or it will delete the token early
in which case we’ll just get a new one. So I think this should be fine, but if
others don’t think we should do this, I’m fine with removing it.
I wasn't able to get MiniKDC working. Having the test working with Kerberos
would be good though, but I don't think it should block getting this fix in.
Once this is in, I'll create another JIRA and upload what I have so far there.
Maybe someone else can figure it out.
> Oozie client keeps trying to use expired auth token
> ---------------------------------------------------
>
> Key: OOZIE-2485
> URL: https://issues.apache.org/jira/browse/OOZIE-2485
> Project: Oozie
> Issue Type: Bug
> Components: client, security
> Affects Versions: trunk
> Reporter: Robert Kanter
> Assignee: Robert Kanter
> Priority: Blocker
> Fix For: trunk
>
> Attachments: OOZIE-2485.001.patch
>
>
> When using Hadoop 2.4.0 or later, the Oozie client doesn't update the auth
> token when it expires. The client doesn't typically give you an error
> because it will still fallback and authenticate via Kerberos or Pseudo.
> However, this is inefficient.
> This appears to be due to HADOOP-10301, which made an incompatible change
> with how the AuthHandler tells the Authenticator when a token has expired.
> It used to give a 401 when the token expired, but now it will do SPNEGO (if
> you have Kerberos credentials) and return a new token, all in the same call.
> Oozie client's code doesn't handle that case.
> With Pseudo Auth, it behaves a little differently and you now get a 403 on
> that first call, but it doesn't give you a new token.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
