Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/534
Hi @mike-tr-adamson, I am glad you entered the discussion. I think your
main point is valid, namely that there are circumstances, pointed out by you,
when gremlin-driver should select the GSSAPI mechanism even though no
JAAS_ENTRY is specified (ToDo: make a test for this to safeguard the desired
behavior).
Having said this, the old behavior (select GSSAPI out of the blue if no
username/password is supplied) also has its risks and problems given the
multitude of SASL mechanisms that people could want to use, see
[http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml](http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml).
Ideally, one would want gremlin-server to provide a token with the
mechanism(s) it supports, so that gremlin-driver can use this to instantiate
the SaslClient properly.
In your case, with `javax.security.auth.useSubjectCredsOnly=false`
configured, you would have a Gremlin-Server with a Krb5Authenticator
configured, the server would provide the GSSAPI token in its authentication
request and gremlin-driver would know to select the GSSAPI mechanism.
However, this ideal situation requires more changes to the gremlin-driver
and gremlin-server code.
I could live now with adding the GSSException as an option to the tests
with your explanation how it could be a valid option. This solves the current
challenge and we can add this discussion as comments to the code for future
reference, when requirements for other SASL mechanisms pop up.
---
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 [email protected] or file a JIRA ticket
with INFRA.
---
