[
https://issues.apache.org/jira/browse/TINKERPOP-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15949621#comment-15949621
]
ASF GitHub Bot commented on TINKERPOP-1657:
-------------------------------------------
Github user robertdale commented on the issue:
https://github.com/apache/tinkerpop/pull/583
One thing I haven't had much time to think about here is how to propagate
ssl client authentication up (into an authentication handler). Right now it's
at the channel level only. That means it is independent of other
authentication mechanisms for better or worse. Permutations to consider:
- needClientAuth REQUIRE, no auth handler: ssl client auth required but no
logging of the client
- needClientAuth REQUIRE, +auth handler: both are always required
- needClientAuth OPTIONAL, no auth handler: same as NO SECURITY!
- needClientAuth OPTIONAL, +auth handler: auth handler always required
So one option is to create ssl client auth's own Channel and Auth Handlers
thus disallowing mixing. One of the limitations of the current system is what
information is available to the Auth handler. So another option is to add
whatever information is required to pass along the fact that ssl client auth
worked then the auth handler could make its own determination as to if further
authentication is required. A more complex option would be to introduce
authentication chaining thus allowing multiple mechanisms and some sort of
requirement scheme - required, sufficient, etc.
I don't know if this PR does help or can help with any of that. Just some
food for thought...
> Provide abstraction to easily allow different HttpAuth schemes
> --------------------------------------------------------------
>
> Key: TINKERPOP-1657
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1657
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
> Reporter: Keith Lohnes
>
> The current HttpChannelizer allows for extension through an Authenticator
> class supplied through the authorization settings. There isn't, however, an
> extension point for an authentication handler. Currently the choice is
> between the `AllowAllAuthenticator` or the `HttpBasicAuthenticationHandler`.
> One would need to create a new channelizer where the HttpChannelizer would
> suffice. Creating an abstract class that can be extended would make it easier
> to extend Authentication for things like token authentication schemes.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
