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...
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
