[
https://issues.apache.org/jira/browse/FLUME-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14337038#comment-14337038
]
Jarek Jarcec Cecho commented on FLUME-2631:
-------------------------------------------
Sqoop client is actually a dependency of the shell that exposes public Java
APIs that users can use to talk to Sqoop 2 server from their Java applications
:) I don't think that we have any active users yet, but considering how many
requests we've seen for public Java API, I'm assuming that it will be used a
lot.
> 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.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)
