You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2015/11/20 11:43:11 UTC

[jira] [Comment Edited] (PROTON-1055) Username sent twice during SASL AUTH

    [ https://issues.apache.org/jira/browse/PROTON-1055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015565#comment-15015565 ] 

Robbie Gemmell edited comment on PROTON-1055 at 11/20/15 10:42 AM:
-------------------------------------------------------------------

I think whats happening is that since support for cyrus sasl was introduced to proton-c the PLAIN initial-response now contains the optional authzid value as well as the authcid, in this case both having the value of the given username.

The other end looks to be ActiveMQ. It would seem it can't handle the authzid being present, which I agree seems like a bug on that end.

[~astitcher] is the man in the know on the proton sasl bits. ANy thoughts Andrew?

Its not clear to me that including the authzid is useful if it can't be configured to a value other than the username (do we have config for that?), and in case that it can't then it may even be incorrect to include it. My reading suggests that the authzid is for requesting to act as *another* identity when you don't want it to be derived from the authcid being presented, so where they are equal it seems redundant (and certainly troublesome in this case) to include it, and also makes the assumption that the derived authzid was going to be equal to the username which as mentioned in the RFC it need not be.


was (Author: gemmellr):
I think whats happening is that since support for cyrus sasl was introduced to proton-c the PLAIN initial-response now contains the optional authzid value as well as the authcid, in this case both having the value of the given username.

The other end looks to be ActiveMQ. It would seem it can't handle the authzid being present, which I agree seems like a bug on that end.

@Andrew Stitcher is the man in the know on the proton sasl bits. ANy thoughts Andrew?

Its not clear to me that including the authzid is useful if it can't be configured to a value other than the username (do we have config for that?), and in case that it can't then it may even be incorrect to include it. My reading suggests that the authzid is for requesting to act as *another* identity when you don't want it to be derived from the authcid being presented, so where they are equal it seems redundant (and certainly troublesome in this case) to include it, and also makes the assumption that the derived authzid was going to be equal to the username which as mentioned in the RFC it need not be.

> Username sent twice during SASL AUTH
> ------------------------------------
>
>                 Key: PROTON-1055
>                 URL: https://issues.apache.org/jira/browse/PROTON-1055
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c, python-binding
>    Affects Versions: 0.10
>         Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 14.04.3 LTS
> Release:        14.04
> Codename:       trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> # python --version
> Python 2.7.6
>            Reporter: Simon Lundstrom
>            Priority: Blocker
>
> In versions >0.9.1.1 (We've tried 0.10 and 0.11.0) the username is sent twice during SASL authentication.
> Working in 0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x250d3b0]:  -> SASL
> [0x250d3b0]:0 -> @sasl-init(65) [mechanism=:PLAIN, initial-response=b"\x00the_username\x00the_password"]
> [0x250d3b0]:  <- SASL
> [0x250d3b0]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x250d3b0]:0 <- @sasl-outcome(68) [code=0]
> [0x250d3b0]:  -> AMQP
> [0x250d3b0]:0 -> @open(16) [container-id="6b1fecb6-358e-48af-b461-bae3563a7c7f", hostname="esb-test"]
> [0x250d3b0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=1]
> [0x250d3b0]:0 -> @attach(18) [name="sender-xxx", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="TEST-queue", durable=0, timeout=0, dynamic=false], target=@target(41) [address="TEST-queue", durable=0, timeout=0, dynamic=false], initial-delivery-count=0]
> [0x250d3b0]:  <- AMQP
> [0x250d3b0]:0 <- @open(16) [container-id="", hostname="", max-frame-size=4294967295, channel-max=32767, idle-time-out=15000, offered-capabilities=@PN_SYMBOL[:"ANONYMOUS-RELAY"], properties={:product="ActiveMQ", :"topic-prefix"="topic://", :"queue-prefix"="queue://", :version="5.12.1", :platform="Java/1.8.0_45"}]
> [0x250d3b0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, incoming-window=0, outgoing-window=0, handle-max=65535]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=1, outgoing-window=0]
> [0x250d3b0]:0 <- @attach(18) [name="sender-xxx", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="TEST-queue"], target=@target(41) [address="TEST-queue"]]
> [0x250d3b0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=2147483647, next-outgoing-id=1, outgoing-window=0, handle=0, delivery-count=0, link-credit=1000]
> [0x250d3b0]:0 -> @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x00\x00\x00\x00\x00\x00\x00\x00", message-format=0, settled=true, more=false] (131) "\x00[…]"
> #
> {code}
> Not working in >0.9.1.1:
> {code}
> # PN_TRACE_FRM=1 ./meow.py
> [0x18aa060]:  -> SASL
> [0x18aa060]:  <- SASL
> [0x18aa060]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x18aa060]:0 -> @sasl-init(65) [mechanism=:PLAIN, initial-response=b"the_username\x00the_username\x00the_password"]
> [0x18aa060]:0 <- @sasl-outcome(68) [code=1]
> [0x18aa060]:  -> EOS
> #
> {code}
> When using >0.9.1.1 and using SSL it does the same BUT then just hangs. Should we open a seperate Jira for this?:
> {code}
> # PN_TRACE_FRM=1 time ./meow.py
> [0xa5d060]:  -> SASL
> [0xa5d060]:  <- SASL
> [0xa5d060]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xa5d060]:0 -> @sasl-init(65) [mechanism=:PLAIN, initial-response=b"the_username\x00the_username\x00the_password"]
> [0xa5d060]:0 <- @sasl-outcome(68) [code=1]
> ^CTraceback (most recent call last):
>   File "./meow.py", line 12, in <module>
>     messenger.send()
>   File "/usr/local/lib/python2.7/dist-packages/proton/__init__.py", line 568, in send
>     self._check(pn_messenger_send(self._mng, n))
> KeyboardInterrupt
> Command exited with non-zero status 1
> 0.08user 0.02system 0:50.69elapsed 0%CPU (0avgtext+0avgdata 12192maxresident)k
> 0inputs+0outputs (0major+5474minor)pagefaults 0swaps
> #
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)