[rabbitmq-discuss] Choosing SASL authentication mechanism

[Simon MacMullen]

On 28/02/11 16:25, Jiri Krutil wrote:
> We are connecting to both brokers using the same Java client (version
> 2.3.1). The Java client uses the default SASL configuration.
>
> When trying to connect, one broker uses the EXTERNAL mechanism as
> expected. But the other broker uses PLAIN authentication (which fails on
> invalid user/password).

Huh. that is weird.

> When we override the default SaslConfig on the client side with a config
> that only has EXTERNAL in the mechanisms list, then both brokers use
> EXTERNAL and things work fine.
>
> So my questions are:
> - How does the broker choose the SASL mechanism to be used?

The broker doesn't choose. The broker offers a list of options to the 
client, and the client chooses one.

In the Java client by default we just invoke 
javax.security.sasl.Sasl.getSaslClient(String[]), which effectively 
leaves the decision up to Sun. The Javadoc here:

http://download.oracle.com/javase/6/docs/api/javax/security/sasl/Sasl.html#createSaslClient(java.lang.String[], 
java.lang.String, java.lang.String, java.lang.String, java.util.Map, 
javax.security.auth.callback.CallbackHandler)

purports to tell you how the selection process works, although it's 
pretty vague - i.e. it "uses the JCA Security Provider Framework".

Having said that, if the brokers are offering the same mechanisms then 
the JCA should at least make a consistent decision. I would hope. But 
maybe not. In theory the order of the mechanisms as reported by the 
broker should not matter, but maybe to JCA it does.

 From your experience I'm starting to wonder if the Java client has the 
right design. All our other clients contain their own SASL 
implementation and you just pick which mechanism you want to use. Maybe 
the Java client should be more like that too.

 > - What installation or configuration mistakes could affect this decision?

If it's the same client both times, I have no idea. If it were different 
clients I would suggest different JDK versions or something similar.

Cheers, Simon

-- 
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware