qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: [qmf] Session pattern
Date Mon, 18 May 2009 14:40:07 GMT
Bryan Kearney wrote:
> I am curious how folks are addressing using QMF in a web application 
> type model. Assume that I have a webapplication which can host n 
> users. If the users can access a backend service via QMF and I want to 
> track on the backend some notion of state and/or who the user is then 
> I seem to need to do the following:
> 1) Have one console instance per user.
> 2) Add the userid (or session id) onto every request and roll my own 
> session cache.
> Has anhyone solved this in a better fashion? This seems analagous to 
> issues with JDBC drivers.. where I may want to track who the user is 
> in the DB.. but not open many connections.
> -- bk
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
This is a good question and it pertains not only to QMF, but more 
generally to messaging.

The QPID broker currently authenticates users at connection setup, one 
user-id per connection.  If authentication fails, the connection is 
closed.  If it is successful, the authenticated user-id may be used by 
the ACL plugin to authorize or forbid specific broker operations.

Message producers may optionally place a user-id into the message header 
of a produced message.  This is used to annotate the message with the 
identity of its originator and can be used by the message's consumers 
for security purposes.  If this field is set in a message, the broker 
compares it to the identity associated with the producer's connection.  
If the message contains an identity different from the connection's 
identity, the message is rejected.  This allows the consumer to trust 
the identity as having been authenticated by the broker.

To handle Bryan's scenario, I claim that option (1) is unacceptable as 
there may be a large number of identities on the front-end.

A application that provides service to multiple users and uses QPID/QMF 
for back-end connectivity should open a single connection to the 
messaging broker and, if other QPID/QMF endpoints in the network need 
the end-user's identity, the user-id field should carry that identity.

Here are some possible mechanisms to support this (I'm sure there are more):

A) Authentication at the Client

Add an ACL action that allows a client to set user-ids that are 
different from the connection identity.  This effectively tells the 
broker to trust this producer to authenticate user-ids.

The application would then use whatever authentication system is in 
place (presumably the same one used by the broker) to authenticate its 
users and would annotate individual messages with the identity of the 
end-user associated with the message.

This option would allow the end-user identities to be separate from the 
broker-user identities (i.e. the user-ids in the messages could be 
completely unknown to the broker).

B) Authenticate Multiple Identities per Connection on the Broker

[I don't care for this one very much]

The broker could provide for some sort of on-the-side SASL exchange for 
each user-id to be associated with a connection.  Of course, such a SASL 
exchange must not involve a security layer.



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

View raw message