[
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,
> RedirectingWebSSOwithJWTforHadoopWebUIs.pdf
>
>
> 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)
