qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Kearney <bkear...@redhat.com>
Subject Re: [qmf] Session pattern
Date Tue, 19 May 2009 12:03:58 GMT
Gordon Sim wrote:
> Ted Ross wrote:
>> 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).
> I prefer option A. I think we already have a work around for the same 
> case in federation (i.e. broker has already authenticated userid on the 
> message) which could perhaps be altered to use the same mechanism as 
> this case (i.e. the ability for a client connection to indicate that it 
> assume responsibility for checking userids on messages and an acl 
> extension to allow this capability to be granted to trusted userids).

This is the JDBC model? If so.. I am fine with it. Question about 
sessions though. Does this mean I have to create my own "startSession()" 
message? That, with the associated pooling and cleanup, seems better 
suited for the engine.

-- bk

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

View raw message