[
https://issues.apache.org/jira/browse/HADOOP-11717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362656#comment-14362656
]
Larry McCay commented on HADOOP-11717:
--------------------------------------
Hi [~wheat9] - good questions. I will try and address them.
First a couple background point that may help in general:
* JWT is a token that is gaining more and more acceptance as a great token to
normalize authentication events that are a result of many different
authentication servers/mechanisms. In fact, a jwt specific OAuth 2 profile is
available: http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
* This patch does not change the existing Hadoop sso tokens. It introduces a
specific type of token - JWT - as a new mechanism for acquiring the hadoop.auth
cookie. We shouldn't try and boil the ocean and do everything for everyone in
this handler.
* This patch provides a very specific behavior - WebSSO through redirect that
results in a JWT token from which the current hadoop auth cookie is created. It
also tries to make it possible for extensions to provide new implementations
for various aspects of the token validation. That said, this is just a one
option to be available where it is appropriate. It is certainly not being made
the default option or a required one.
* It will likely be extended to add support for other ways to get a JWT from
the request at some point in the future.
1. OAuth 2.0 - there is nothing about this patch that precludes us from adding
a similar handler for OAuth or any other protocol as we see fit. This patch
introduces support for WebSSO type flows for UIs. Perhaps, OAuth 2.0 can be
accommodated within this flow where it would result in a JWT token or perhaps
we would add another handler altogether.
2. As I described about the auth cookie in Hadoop continues to be the existing
cookie - this patch provides a new token that can be used like a credential for
acquiring a hadoop auth cookie. We aren't changing how things currently work -
just providing an alternative that allows for certain integration capabilities.
3. I don't see any real need to separate the redirecting capability of this
patch from the specific type of token for a couple reasons: the redirecting
capability alone is very simple and doesn't require an abstract or base class,
the JWT processing available in the nimbus-jose-jwt library is quite succinct
and easily understood and we can always refactor them apart later if the need
arises. In the absence of other usecases, I think it is premature to provide
the separation.
4. HMAC vs RSA - this is an interesting topic. This really comes down to HMAC
vs PKI. While either can be used to provide integrity checking and establish
trust relationships, HMAC requires a shared secret between the parties. This
means that the secret must be available to both the signer and the consumer of
the HMAC. In Hadoop this means that it must be available to many different
processes/system users. The more such a secret is available the more easily it
is compromised. PKI on the other hand only requires the public key be
distributed to the consumers. It doesn't have to be kept completely secret like
a shared secret because - it is public. You just have to know that you got it
from a trusted party. An admin setting the PEM as a configuration element
provides exactly that level of trust without requiring a secret distribution
mechanism and encrypted storage of the key. I am actually considering providing
a signer secret provider and some refactoring that is based on PKI as well.
This would provide the same benefits for distribution and storage for the
delegation and hadoop auth tokens.
I hope that these points explain my design choices here. I plan to provide a
design document for this improvement that spells out the configuration and
implementation clearly.
Thank you for the very good questions!
> 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,
> HADOOP-11717-3.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)
