SASL mechanism different between 0.9.1 and 0.10

[Paolo Patierno <pp...@live.com>]

Hi all,I noticed the following difference between 0.9.1 and 0.10 and I'm not able to use Qpid Proton C 0.10 for sending messages to Azure Service Bus (a queue for example).The endpoint is the same for both :
amqps://<username>:<password>@<namespace>.servicebus.windows.net/q1
I'm using the "send" example in the Proton solution (Visual Studio 2015 under Windows 10).
With 0.9.1 the message is sent correctly to the Service Bus queue but it doesn't happen with version 0.10.
Enabling the PN_TRACE_FRM I can see a big difference ...
With 0.9.1 version the SASL mechanism is PLAIN and it's correct. With 0.10 version the SASL mechanism is EXTERNAL, so after some messages exchanges I receive the unauthorized access with a claim needed. It's right because I'm not sending the SAS token to Azure (needed by the AMQP Claim Based Security specification).
0.9.1 ......
[011FDF28]:  -> SASL
[011FDF28]:0 -> @sasl-init(65) [mechanism=:PLAIN, initial-response=b"\x00RootManageSharedAccessKey\x00<mysecretkey>"]
[011FDF28]:  <- SASL
0.10 ....
[00D9D160]:  -> SASL
[00D9D160]:  <- SASL
[00D9D160]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :EXTERNAL]]
[00D9D160]:0 -> @sasl-init(65) [mechanism=:EXTERNAL, initial-response=b"RootManageSharedAccessKey"]....[00D9D160]:0 <- @detach(22) [handle=0, closed=true, error=@error(29) [condition=:"amqp:unauthorized-access", description
="Unauthorized access. 'Send' claim(s) are required to perform this operation. Resource: 'sb://qpidprotontest.servicebus
.windows.net/q1'. TrackingId:c5a321fd35e7461f83846bbcef5e42ff_G34,TimeStamp:9/1/2015 2:12:36 PM"]]
My question is why the two version have these two different behaviors ?It's the client to propose the PLAIN in 0.9.1 and EXTERNAL in 0.10.
Attached you can find the two different trace (I removed <mysecretkey>).
With these changes seems that the current 0.10 version doesn't work with Azure Service Bus.
Thanks,Paolo.

Paolo PatiernoSenior Software Engineer
 

Windows Embedded & IoTMicrosoft Azure Insider 
Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperienceBlog : Embedded101
 		 	   		  

Re: SASL mechanism different between 0.9.1 and 0.10

[Andrew Stitcher <as...@redhat.com>]

On Tue, 2015-09-01 at 14:32 +0000, Paolo Patierno wrote:
> Hi all,
> I noticed the following difference between 0.9.1 and 0.10 and I'm not
> able to use Qpid Proton C 0.10 for sending messages to Azure Service
> Bus (a queue for example).

You don't say whether you are using Proton-C 0.10 on Windows or Unix
(this can now make a significant difference).

The Proton-C SASL implementation has been completely changed for 0.10.
Previously SASL was only implemented for ANONYMOUS and PLAIN and so
EXTERNAL could never have been selected. Now all of these mechanisms
are supported on both Windows and Unix.

The Unix implementation will also use the Cyrus SASL library to offer
some other mechanisms too.

It looks like you are running SSL around AMQP with client certificates
and I think this is why EXTERNAL is being picked to use by the client,
as in general the Proton-C SASL implementations wiil choose a "more
secure" mechanism if it is possible. And EXTERNAL is considered more
secure than PLAIN.

If you want to limit the client to using PLAIN then you should add a
line like:
	pn_sasl_allow_mechs(sasl, "PLAIN"); 
to your application (it will be a bit different depending on which
language you are using).

HTH

Andrew
 
> The endpoint is the same for both :
> 
> amqps://<username>:<password>@<namespace>.servicebus.windows.net/q1
> 
> I'm using the "send" example in the Proton solution (Visual Studio
> 2015 under Windows 10).
> 
> With 0.9.1 the message is sent correctly to the Service Bus queue but
> it doesn't happen with version 0.10.
> 
> Enabling the PN_TRACE_FRM I can see a big difference ...
> 
> With 0.9.1 version the SASL mechanism is PLAIN and it's correct. With
> 0.10 version the SASL mechanism is EXTERNAL, so after some messages
> exchanges I receive the unauthorized access with a claim needed. It's
> right because I'm not sending the SAS token to Azure (needed by the
>  AMQP Claim Based Security specification).

Could you point me to this specification? I've never heard of it
before. Is it an Azure specific thing?

> 
> 0.9.1 ......
> 
> [011FDF28]:  -> SASL
> [011FDF28]:0 -> @sasl-init(65) [mechanism=:PLAIN, initial
> -response=b"\x00RootManageSharedAccessKey\x00<mysecretkey>"]
> [011FDF28]:  <- SASL
> 
> 0.10 ....
> 
> [00D9D160]:  -> SASL
> [00D9D160]:  <- SASL
> [00D9D160]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMB
> OL[:PLAIN, :EXTERNAL]]
> [00D9D160]:0 -> @sasl-init(65) [mechanism=:EXTERNAL, initial
> -response=b"RootManageSharedAccessKey"]
> ....
> [00D9D160]:0 <- @detach(22) [handle=0, closed=true, error=@error(29)
> [condition=:"amqp:unauthorized-access", description
> ="Unauthorized access. 'Send' claim(s) are required to perform this
> operation. Resource: 'sb://qpidprotontest.servicebus
> .windows.net/q1'.
> TrackingId:c5a321fd35e7461f83846bbcef5e42ff_G34,TimeStamp:9/1/2015
> 2:12:36 PM"]]
> 
> My question is why the two version have these two different behaviors
> ?
> It's the client to propose the PLAIN in 0.9.1 and EXTERNAL in 0.10.
> 
> Attached you can find the two different trace (I removed
> <mysecretkey>).
> 
> With these changes seems that the current 0.10 version doesn't work
> with Azure Service Bus.

I have actually tested it with some (simple) service bus scenarios, so
I know it does work (at least in the scenarios I tested)

Andrew



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