hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry McCay (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11717) Add Redirecting WebSSO behavior with JWT Token in Hadoop Auth
Date Mon, 16 Mar 2015 01:56:38 GMT

    [ 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)

Mime
View raw message