hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kai Zheng (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11717) Add Redirecting WebSSO behavior with JWT Token in Hadoop Auth
Date Tue, 07 Apr 2015 05:25:12 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482617#comment-14482617

Kai Zheng commented on HADOOP-11717:

Thanks for the update.
bq.there is no reason to encrypt and decrypt here - the assumption is that they are to be
protected with transport security.
Sorry for my late response. I don't quite agree with this, as transport security is used to
protect token from being leaked, and the encryption layer in token itself can be used to protect
sensitive identity privacy, which means if someone loses his/her token, he/she won't suffer
from exposing any sensitive credential identity attributes. I thought that's why JWE is defined
and required. I understand in your case/requirement/scenario you may not use encryption feature,
but it can be useful for others. I do think we can leave this aspect for future consideration,
like tasks in HADOOP-11766. 

I missed to mention another point. Why we couple this with {{AltKerberosAuthenticationHandler}}?
I thought a dedicated authentication handler like {{AuthTokenAuthenticationHandler}} may make
more sense. Still, this may be handled separately if sounds good.

Another point made by [~wheat9] here, which was also widely discussed before, it would be
good to have a generic token abstract from JWT stuff. Again, I would follow up on this in
HADOOP-11766 tasks.

We still need to think about how to apply this new mechanism across all the web interfaces
for HDFS and YARN. Will fire another task for this.

Related to above points, to make the work more general, I suggest we change the following
configuration items.
authentication.provider.url => token.authentication.provider.url
public.key.pem => token.signature.publickey;
expected.jwt.audiences => expected.token.audiences;

Maybe it's a little late to mention these. What I'm worrying about is once we have this in
the trunk, we're then not able to enhance or follow up easily in the following. Any good idea
for the concern? Thanks!

> 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,
HADOOP-11717-4.patch, HADOOP-11717-5.patch, HADOOP-11717-6.patch, HADOOP-11717-7.patch, HADOOP-11717-8.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

View raw message