[
https://issues.apache.org/jira/browse/FLUME-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14347400#comment-14347400
]
Johny Rufus commented on FLUME-2631:
------------------------------------
@Ryan, I thought about having directly returning an executor, I still followed
the original approach, if we want to support some other methods in the
authenticator which the client needs access to, other than executor. But for
now, its not needed, I agree.
I named the Executor as FlumeExecutor, PriviligedExecutor also makes sense.
> End to End authentication in Flume
> -----------------------------------
>
> Key: FLUME-2631
> URL: https://issues.apache.org/jira/browse/FLUME-2631
> Project: Flume
> Issue Type: New Feature
> Components: Sinks+Sources
> Reporter: Johny Rufus
> Assignee: Johny Rufus
> Fix For: v1.6.0
>
> Attachments: FLUME-2631-1.patch, FLUME-2631.patch
>
>
> 1. The idea is to enable authentication primarily by using
> SASL/GSSAPI/Kerberos with Thrift RPC. [Thrift already has support for SASL
> api that supports kerberos, so implementing right now for Thrift. For Avro
> RPC kerberos support, Avro needs to support SASL first for its Netty Server,
> before we can use it in flume]
> 2. Authentication will happen hop to hop[Client to source, intermediate
> sources to sinks, final sink to destination].
> 3. As per the initial model, the user principals won’t be carried forward.
> The flume client[ThriftRpcClient] will authenticate itself to the KDC. All
> the intermediate agents [Thrift Sources/Sinks] will authenticate as principal
> ‘flume’ (typically, but this can be any valid principal that KDC can
> autenticate) to each other and the final agent will authenticate to the
> destination as the principal it wishes to identify to the destination
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
