[
https://issues.apache.org/jira/browse/YARN-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295134#comment-15295134
]
Allen Wittenauer commented on YARN-4006:
----------------------------------------
bq. Is the usecase description part of a proprietary solution that we don't
want to expose for some reason?
Yes.
bq. 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.
... which would break folks who are using, e.g., SAML. There are definitely
handlers out in the wild for all sorts of weird things.
bq. If we want to be able to use custom authentication handlers here than we
need the change proposed by this patch.
I'm left with the question of "why should timeline server be handled
differently than every other serving process in Hadoop?" Even the 2NN allows
for a custom authentication handler. It basically makes the TS seem like a
significantly lower quality service if it can only use two auth handlers when
it only supports REST as a connection point!
bq. What are the different client types for this endpoint and how (if at all)
does a proxy come into play for each?
Automated processes that are outside the network to build reporting and what
not. They will not have access to a kdc to use for authentication. A network
hole will be punched that will allow for IP redirection. Also note that they
can add custom user-agent strings...
bq. What would be examples of the non-kerberos side of the AltKerberos
JWT is definitely one of them. The other is an OTP string in a custom HTTP
header.
FWIW: I completely agree that this whole mess would go away if either
AltKerberos was smarter and/or there was a generic AuthenticationHandler hook
that every daemon used. But Hadoop being Hadoop, the latter was never an
option given how often individual teams working on individual components seem
to be stuck permanently in NIH mode. "Oh, the NN needs to do this little bit
different for the 2NN" is what started the downward spiral here. :(
> 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]
