[
https://issues.apache.org/jira/browse/HADOOP-11717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362410#comment-14362410
]
Larry McCay commented on HADOOP-11717:
--------------------------------------
Thanks for the review, Kai.
I will address as many of the comments that you raise as appropriate for this
iteration and provide a new patch.
I'll try and address our comments/questions here to help clarify:
* I believe that updating both poms is necessary in order to avoid putting the
version of the new dependency in the hadoop-auth module. They get spelled out
specifically in hadoop-project and referenced in the other modules. NOTE:
bouncy castle is being excluded for this patch. There is nothing in the WebSSO
usecase that requires it.
* I agree with your assertion that the token should only be sent over SSL. This
should be managed by the authentication server that creates the cookie. It must
be able to be set to Secure only.
* For WebSSO - I see the use of a cookie as fine and it aligns with the current
usage of the hadoop.auth token in Hadoop. At some point later we could add a
POST profile if there is a need.
* I will limit the use of the word cookie as you suggest and ensure that it is
just one way to acquire the token from the request. I already had this in mind
for a later improvement - as I want to add support for JWT as a bearer token as
well.
* The bearer token usecase I mentioned above would be useful REST calls and is
what I have in mind there. However, this patch does not introduce support for
webhdfs or other REST servers yet. We will tackle them after this gets in.
* Since the intent of the JWT token at this point is to allow for the creation
of the hadoop.auth cookie, it can and should have a shorter lived expiration
date. Just long enough to make sure that the normal hadoop cookie can be
acquired. Tying their lifetimes together wouldn't add any value there.
* I will refactor the handleJWTToken as you suggest
* userName will be whatever the authentication server provides in the JWT. It
will only ever be as unique as asserted by the issuer.
* The message regarding the header and footer actually is correct. The required
configuration is the PEM encoded certificate *without* the header and footer.
This is actually the same way that public keys are configured in shibboleth and
works well. The wording of the message needs to be improved to make sure that
it is clear.
* Yes, we only support a PEM configuration element for the public key in this
patch. There is however a method for setting the RSAPublicKey directly that is
only used in tests at the moment. We can add KeyProvider API support for
getting the public key later - if that makes sense. I actually find the
configuration approach preferable. It can easily be added through a management
console, it is a public key - so the file permissions protection for the config
file is plenty of protection.
I will post a new patch today.
Thanks again!
> Add Redirecting WebSSO behavior with JWT Token in Hadoop Auth
> -------------------------------------------------------------
>
> Key: HADOOP-11717
> URL: https://issues.apache.org/jira/browse/HADOOP-11717
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Larry McCay
> Assignee: Larry McCay
> Attachments: HADOOP-11717-1.patch, HADOOP-11717-2.patch
>
>
> Extend AltKerberosAuthenticationHandler to provide WebSSO flow for UIs.
> The actual authentication is done by some external service that the handler
> will redirect to when there is no hadoop.auth cookie and no JWT token found
> in the incoming request.
> Using JWT provides a number of benefits:
> * It is not tied to any specific authentication mechanism - so buys us many
> SSO integrations
> * It is cryptographically verifiable for determining whether it can be trusted
> * Checking for expiration allows for a limited lifetime and window for
> compromised use
> This will introduce the use of nimbus-jose-jwt library for processing,
> validating and parsing JWT tokens.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
