[
https://issues.apache.org/jira/browse/BOOKKEEPER-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688855#comment-13688855
]
Sijie Guo commented on BOOKKEEPER-390:
--------------------------------------
{quote}
I don't quite understand the middleware thing though. Does the #isAuth() check
if the particular request (such as a write to ledger metadata) is authorized?
If not should it do the authorization? I think it may be better to have auth as
a first class citizen in the ledger manager, as it's actually the client that
the ledger manager uses that does the authentication.
{quote}
I am OK with any authentication interfaces you guys are working on. My opinion
is that not every application needs authentication, the authentication should
not be tightly bound with bookkeeper core itself and it is easy to plugin
different authentication implementation.
in general, there are two parts in bookkeeper that we need to authenticate, one
part is metadata, while the other part is data. as I suggested in previous
comment, a separated auth ledger manager would address metadata authentication,
without modifiying the metadata flow.
the *middleware* concept I tried to introduce in previous comment is to
providing a *hook* to intercept data request processing (not metadata request)
for different purposes, which could be used to handle data authentication
(bookie authentication) without modifying data flow. I wrote a simple patch to
describe how *middleware* looks, how it works and how it helps in bookie
authentication last night. I would open a separated ticket for it.
> Provide support for ZooKeeper authentication
> --------------------------------------------
>
> Key: BOOKKEEPER-390
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-390
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.0.0
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 4.3.0
>
> Attachments: BOOKKEEPER-390-Acl-draftversion.patch,
> BOOKKEEPER-390-Authentication-interfaces-draftversion.patch
>
>
> This JIRA adds support for protecting the state of Bookkeeper znodes on a
> multi-tenant ZooKeeper cluster.
> Use case: When user tries to run a ZK cluster in multitenant mode, where
> more than one client service would like to share a single ZK service instance
> (cluster). In this case the client services typically want to protect their
> data (ZK znodes) from access by other services (tenants) on the cluster. Say
> you are running BK, HBase or ZKFC instances, etc... having
> authentication/authorization on the znodes is important for both security and
> helping to ensure that services don't interact negatively (touch each other's
> data).
> Presently Bookkeeper does not have support for authentication or
> authorization while accessing to ZK. This should be added to the BK
> clients/server that are accessing the ZK cluster. In general it means calling
> addAuthInfo once after a session is established
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
