Java Client -> C++ broker anonymous authentication weirdness - does anyone know this stuff??

[Fraser Adams <fr...@blueyonder.co.uk>]

Hi All,
I've been engaged in a conversation with Bruno Matos on this group where 
we appear to be seeing different results :'( .

In my GUI's underlying ConnectionHelper class I'd set user/passwd 
defaults to guest:guest when no explicit user/passwd were supplied 
(probably incorrectly on my part, but that's by the by).

Bruno gave this a tweak and set them to default to anonymous:anonymous 
and reckoned it worked for him, but for my part any time I tried 
enabling qpidd --auth yes I got "warning Failed to retrieve sasl 
username" from the broker if I did this.

Bruno enabled logging so I can see the Java ConnectionURLs that 
ConnectionHelper creates so for his "anonymous-anonymous-auth-yes.txt" 
test case, the ConnectionURL he got was:

amqp://anonymous:anonymous@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672'

However when I tried that URL either in my GUI or in a jndi file for a 
simple consumer test client my broker barfs with the error above.

However..... I then had a bit of a tinker and created a URL of:

amqp://anonymous:anonymous@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672?sasl_mechs='ANONYMOUS''

And that actually worked.....


So I'm thinking that there might have been some changes between Qpid 
versions? I've currently got the 0.20 Java jars on my classpath, but my 
broker is still 0.12, but Bruno reckons he's been using 0.18 at home and 
I think 0.14 at work so my hunch is that something might be different 
between the brokers?

Incidentally I also found that:

amqp://:@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672?sasl_mechs='ANONYMOUS''

Worked for me too so it seems to be the explicit setting of 
sasl_mechs='ANONYMOUS' that is significant.


Could someone please explain how this hangs together (and is my 
observation about right?).

What I'd really like to do is to put a fix into my code that will behave 
correctly irrespective of the broker/client runtime version. It looks 
like Bruno doesn't have to explicitly add the sasl_mechs bit for 
anonymous, but does it hurt? So for example if in my ConnectionHelper if 
I don't get an explicit username or password as part of the input and I 
default to an output URL of the form

amqp://:@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672?sasl_mechs='ANONYMOUS''

Is that likely to be an issue? Clearly this would be a bad thing to do 
if an actual username was supplied :-)


I'm a little baffled as I'd have thought this might have been on the 
client side, but I'm using a newer version of that than Bruno, so I'm 
guessing there's some negotiation from the broker that's perhaps changed?


Is there a better way of allowing anonymous connections from JMS (that 
works across different Qpid versions) than me explicitly adding 
?sasl_mechs='ANONYMOUS' when a username/passwd aren't supplied.

According to the BNF for Java ConnectionURLs the username/password bit 
is optional, but Pavel Moravec pointed me at

  https://issues.apache.org/jira/browse/QPID-3396  

So there's a bug that means it's not actually *optional*. I guess even 
if that gets fixed it will only be the case for more recent Qpid 
versions, so I'm thinking that explicitly setting sasl_mechs in my code 
might be the most reliable way to cover a wide range of Qpid versions, 
is that about right?


Is there an unwritten rule somewhere that anything to do with 
authentication has to come under the subtype of "Voodoo Magic" :-)

MTIA,
Frase



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

Re: Java Client -> C++ broker anonymous authentication weirdness - does anyone know this stuff??

[Gordon Sim <gs...@redhat.com>]

On 02/02/2013 12:02 PM, Fraser Adams wrote:
> So I'm thinking that there might have been some changes between Qpid
> versions? I've currently got the 0.20 Java jars on my classpath, but my
> broker is still 0.12, but Bruno reckons he's been using 0.18 at home and
> I think 0.14 at work so my hunch is that something might be different
> between the brokers?

I don't think anything has changed on the broker side in that regard. I 
strongly suspect any change in behaviour is on the client side.

[...]
> it seems to be the explicit setting of
> sasl_mechs='ANONYMOUS' that is significant.
[...]
> Could someone please explain how this hangs together (and is my
> observation about right?).

The mechanism is chosen by the client. If not explicitly specified it 
should pick one of the mutually supported ones (ideally the 'most secure').

My guess is that something has changed on the client side around the 
selection of a mechanism when none is provided(?). I can't say for sure 
however (the only relatively recent change I saw in the logs was: 
http://svn.apache.org/viewvc?view=revision&revision=1424556).

Anyone more fmailiar with the JMS client able to comment on the logic 
involved in selecting a SASL mechanism when it has not been explicitly 
chose through the 'URL'? Or on any recent changes to that?

> What I'd really like to do is to put a fix into my code that will behave
> correctly irrespective of the broker/client runtime version. It looks
> like Bruno doesn't have to explicitly add the sasl_mechs bit for
> anonymous, but does it hurt? So for example if in my ConnectionHelper if
> I don't get an explicit username or password as part of the input and I
> default to an output URL of the form
>
> amqp://:@QpidJMS/vhost?brokerlist='tcp://0.0.0.0:5672?sasl_mechs='ANONYMOUS''
>
>
> Is that likely to be an issue? Clearly this would be a bad thing to do
> if an actual username was supplied :-)

Ultimately I think you may want to allow the acceptable mechanisms to be 
supplied as well as the username and password.

However, I would also say that I think the issue Bruno hit sounds very 
much like a JMS client bug. The client should only set the userid to the 
*actual* authenticated user and it sounds like that may not be the case. 
I think we should raise a JIRA for that anyway.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org