[
https://issues.apache.org/jira/browse/YARN-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295124#comment-15295124
]
Larry McCay commented on YARN-4006:
-----------------------------------
[~aw] - this is entirely dependent on the proxy and whether it can be
configured as a trusted proxy in hadoop. Knox is certainly a proxy that
authenticates via kerberos and asserts the doas identity.
That aside, I am still unclear on how AltKerberos can help that particular
usecase. Non-browsers are intended to use kerberos in AltKeberos extensions.
This may already be understood by you but I can't tease out the usecase being
addressed here without an end to end description.
Is the usecase description part of a proprietary solution that we don't want to
expose for some reason?
Not trying to be snarky here - just would like to understand the reluctance.
* From what I can see, if a custom authentication handler (forget AltKerberos
for a moment) is configured than the TimelineAuthenticationFilterInitializer
will not add it or the Pseudo or Kerberos handlers to the FilterConfig.
* If we don't care about custom authentication handlers here then we could
change the patch to default to kerberos when there is a custom authentication
handler configured. This would be assuming that any custom handler would be an
AltKerberos impl and would likely require there to be no browser useragents in
play at this endpoint or that they have SPNEGO enabled if there are.
* If we want to be able to use custom authentication handlers here than we need
the change proposed by this patch.
* If we don't have browser based useragents in play here then we don't - by
definition - need AltKerberos extensions here but by having custom
authentication handlers available you could use them but only the kerberos side
would be used.
Let's try simplified questions:
1. What are the different client types for this endpoint and how (if at all)
does a proxy come into play for each?
2. What would be examples of the non-kerberos side of the AltKerberos (can we
use JWT based cookie for example)?
> YARN ATS Alternate Kerberos HTTP Authentication Changes
> -------------------------------------------------------
>
> Key: YARN-4006
> URL: https://issues.apache.org/jira/browse/YARN-4006
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: security, timelineserver
> Affects Versions: 2.5.0, 2.6.0, 2.7.0, 2.5.1, 2.6.1, 2.8.0, 2.7.1, 2.7.2
> Reporter: Greg Senia
> Assignee: Greg Senia
> Priority: Blocker
> Attachments: YARN-4006-branch-trunk.patch,
> YARN-4006-branch2.6.0.patch, sample-ats-alt-auth.patch
>
>
> When attempting to use The Hadoop Alternate Authentication Classes. They do
> not exactly work with what was built with YARN-1935.
> I went ahead and made the following changes to support using a Custom
> AltKerberos DelegationToken custom class.
> Changes to: TimelineAuthenticationFilterInitializer.class
> {code}
> String authType = filterConfig.get(AuthenticationFilter.AUTH_TYPE);
> LOG.info("AuthType Configured: "+authType);
> if (authType.equals(PseudoAuthenticationHandler.TYPE)) {
> filterConfig.put(AuthenticationFilter.AUTH_TYPE,
> PseudoDelegationTokenAuthenticationHandler.class.getName());
> LOG.info("AuthType: PseudoDelegationTokenAuthenticationHandler");
> } else if (authType.equals(KerberosAuthenticationHandler.TYPE) ||
> (UserGroupInformation.isSecurityEnabled() &&
> conf.get("hadoop.security.authentication").equals(KerberosAuthenticationHandler.TYPE)))
> {
> if (!(authType.equals(KerberosAuthenticationHandler.TYPE))) {
> filterConfig.put(AuthenticationFilter.AUTH_TYPE,
> authType);
> LOG.info("AuthType: "+authType);
> } else {
> filterConfig.put(AuthenticationFilter.AUTH_TYPE,
> KerberosDelegationTokenAuthenticationHandler.class.getName());
> LOG.info("AuthType: KerberosDelegationTokenAuthenticationHandler");
> }
> // Resolve _HOST into bind address
> String bindAddress = conf.get(HttpServer2.BIND_ADDRESS);
> String principal =
> filterConfig.get(KerberosAuthenticationHandler.PRINCIPAL);
> if (principal != null) {
> try {
> principal = SecurityUtil.getServerPrincipal(principal, bindAddress);
> } catch (IOException ex) {
> throw new RuntimeException(
> "Could not resolve Kerberos principal name: " + ex.toString(),
> ex);
> }
> filterConfig.put(KerberosAuthenticationHandler.PRINCIPAL,
> principal);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
