[
https://issues.apache.org/jira/browse/BOOKKEEPER-959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636848#comment-15636848
]
Enrico Olivelli commented on BOOKKEEPER-959:
--------------------------------------------
I have updated the PR with the following changes:
- rename AuthMessageData to AuthToken
- fix the auth required/auth disabled flow
My proposal to support the switch from "no-auth" to any plugin is the following:
1) when no auth is configured on bookie-side the default auth plugin comes to
play. I'm going to change its name from "nullplugin" to "AuthDisabledPlugin"
2) when no auth is configured on bookies the bookie goes to a permissive mode
in which any client is allowed to connect and use bookie functions, any 'auth'
message will be answered with an OK status code from the AuthDisabledPlugin
3) when no auth is configured on bookies each attempt of authentication by the
client will receive the OK status code from the AuthDisabledPlugin, and so the
client will understand that the bookie is not performing authentication, and
goes to the authenticated state
A rolling upgrade from AuthDisabledPlugin to any other plugin can be
implemented by rebooting clients with the new plugin: this way bookies will
authenticate clients with AuthDisabledPlugin and clients will go to
authenticated state anyway.
Then you will restart bookies with the new plugin and clients will perform real
authentication.
Beware that bookie-to-bookie comunications will follow the same scheme during
the rolling upgrade, because each bookie can be a client for the other bookies
and will authenticate thru the AuthDisabledPlugin flow or to the requested
plugin flow.
[~rakeshr] [~merlimat] does this flow sound good to you?
Another issue will be to attach to the server-side view of the connection the
user-id (principal) of the client which performed authentication, this will be
the base for authorization.
A change to the AuthProvider interface will be needed.
I wonder if we have to add this feature now as we are breaking compatibility
with 4.4
[~hustlmsp] do you think that the discussion should continue on
https://cwiki.apache.org/confluence/display/BOOKKEEPER/BP-3+-+Security+support
?
> ClientAuthProvider and BookieAuthProvider Public API used Protobuf Shaded
> classes
> ---------------------------------------------------------------------------------
>
> Key: BOOKKEEPER-959
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-959
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client, bookkeeper-server
> Affects Versions: 4.4.0
> Reporter: Enrico Olivelli
> Assignee: Enrico Olivelli
> Priority: Blocker
> Fix For: 4.5.0
>
>
> With 4.4.0 we introduced the ability to implement custom authentication
> plugins.
> The new interfaces ClientAuthProvider and BookieAuthProvider depend on
> ExtensionRegistry, which is a shaded dependency.
> As a consequence it is not possibile to implement any custom auth provider in
> code outside the project, because shaded/relocated dependencies cannot be
> used.
> We need to break the actual interface and introduce a new way to implement
> such plugins in a portable way
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
