On 15/06/18 16:35, Andrew Stitcher wrote:
There is a long standing pain point with using cyrus SASL: If you have
Kerberos set up in your environment; are authenticated with Kerberos;
and have the GSSAPI mechanism installed; but you are not using the
ambient Kerberos credential for AMQP.
In this case (which is common, at least in Red Hat internal
environments) A Cyrus SASL client will pick Kerberos as the mechanism
even though the server doens't have a ticket and the authentication
fails immediately without any further SASL negotiation (this might be a
bug in Cyrus, but I don't think it's ever going to be fixed if so).
This is recorded as a JIRA [1] which has been open for a couple of
years.
You can of course also specify a mech list in the cyrus sasl config.
The solution to this problem is not to offer/accept the GSSAPI or GSS-
SPNEGO mechanisms by default. This should give the least surprising
default experience.
I have a PR [1] avalable which does just this. It works like this:
If the user has explicitly set the SASL mechanisms that are allowed
then these are all used on both server and client. If no allowed
mechanisms are set it filters out the problematic mechanisms from both
the mechanisms offered by the server and the mechanisms that are
considered by the client.
I think this is simple and straigtforward, however it changes the
mechanism selection semantic significantly if you actually want
Kerberos.
To me it, this solves one usability issue at the expense of creating
another. The argument for it would be that the issue solved affects more
people than the issue created and I have no evidence to the contrary.
My own inclination would be to leave things as they are without clear
evidence that this is a change users would prefer, but I wouldn't oppose
a different view.
For instance there is actually *no way* to return to the current
semantic of offering/selecting all possible mechanisms if you don't
already know what they are (there is no way to query the available
mechanisms in the pn_sasl API).
Is this important? If it is, there are a number of possible solutions -
all involving some extra API complexity. I'd prefer to avoid this if
possible, as I believe that simpler APIs are just easier to
use/understand as long as they allow you to do what is needed.
1. The simplest way to return to the previous semantic would be to have
a new API named something pn_sasl_set_allow_problematic_mechs() - in
line with the existing pn_sasl_set_allow_insecure_mechs(). This would
return the semantic to the existing one.
I think 'problematic' is the wrong term to use there (seems somewhat
libelous!).
2. Special case selecting "" - the empty string as the allowed
mechanisms. Currently using pn_sasl_allowed_mechs to "" is useless as
it will not allow *any* mechs to be selected. So this could be used as
a (hacky) way to return to the previous semantic without any extra APIs
being introduced and without affecting existing code as no one could be
doing this currently. Personnally I don't favour this idea as I prefer
something expicit, and this would be strange implicit behaviour.
3. Introduce a concept of excluded mechanisms. There'd be a new API
called something like pn_sasl_excluded_mechs() which would set the
excluded mech list. It would default to "GSSAPI GSS-SPNEGO", but you
could set it to "" if you wanted the previous behaviour. This would
also allow the possiblility of excluding other mechanisms of you wanted
that for whatever reason. On the whole I don't really like this idea as
it complicates the API and semantics for little apparent gain and
raises the question of the detailed interaction of the excluded/allowed
mechanisms.
My current thinking is that I should merge the PR [2] and see if anyone
is affected by the change, if so then I prefer solution 1. What do
other people think?
Andrew
[1] https://issues.apache.org/jira/browse/PROTON-1354
[2] https://github.com/apache/qpid-proton/pull/148
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
