Re: Checking message's userid against authenticated SASL user (was Re: Qpid Cluster Errors)

[Rajith Attapattu <ra...@gmail.com>]

On Thu, Dec 17, 2009 at 6:47 AM, Gordon Sim <gs...@redhat.com> wrote:
> On 12/17/2009 02:37 AM, Sandy Pratt wrote:
>>
>> Thanks Alan.  I made a new build from trunk and things are going well so
>> far, except that when I enable auth=yes, I get the following:
>>
>> 2009-12-16 18:33:18 error qpid/amqp_0_10/SessionHandler.cpp:97: Execution
>> exception: unauthorized-access: authorised user id : prattrs@QPID but user
>> id in message decla
>> red as prattrs (qpid/broker/SemanticState.cpp:435)
>>
>> I'm pretty sure the password is correct, because if I change it I get an
>> entirely different authentication error.
>
> I think this is due to a change in the way the broker checks the userid set
> on a message[1]. For e.g. GSSAPI based authentication it is important that
> this includes the domain[2]

The commit made in rev 819819 does not resolve the issue defined in QPID-2129
The problem described in QPID-2129 is due to the broker not using the
proper domain (even when using kerberos as the auth mechanism).
So the userID maintained in the connection seems to use the default
realm "QPID". Ex "qpidd/srv.ovirt-demo.com@QPID"
The ruby client seems to set the user id properly. Ex
"qpidd/srv.ovirt-demo.com@OVIRT-DEMO.COM"

The commit made in rev 819819 is covered by QPID-2175.

> However for PLAIN authentication I think the realm is added as a 'pseudo'
> domain by cyrus-sasl and I'm not sure the client can in general know
> this(?).
It seems the default realm "QPID" is added irrespective of the auth
mechanism used.
Check the above and QPID-2129.

I don't think the client needs to know the default realm.
And it does not need to supply a domain unless it uses something like
kerberos (QPID-2174)
The broker should add the default domain to the userID supplied in the
message (as it does to a user without a domain when authenticating the
connection) when authorizing a message transfer.

Also you cannot modify the Java client to add a domain by default as
the Java broker has no notion of a domain.
However I plan to add the userID and domain in the JMS client
(ignoring the one set in the connection) if  Kerberos is used as the
auth mechanism.
This will not be a problem as the Java broker currently doesn't
support Kerberos auth. When it does the Java broker would also need to
handle the domain.

> I'm not sure what the best fix is here. Perhaps the checking on the broker
> should just be a little cleverer and should not fail if the client has not
> specified a domain in the userid property of a message and the userid is in
> the 'default' domain (named after the realm)?
>
> Any thoughts?

This is exactly what I have done. Will check in my fix after running the tests.

> I've raised a JIRA for this[3]. As it is a regression for some cases I think
> it is a blocker for 0.6 and have marked it as such.
>
> [1]
> http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp?r1=819819&r2=819818&pathrev=819819
> [2] https://issues.apache.org/jira/browse/QPID-2129
> [3] https://issues.apache.org/jira/browse/QPID-2290
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>



-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org