You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Bryan Kearney <bk...@redhat.com> on 2009/04/16 00:05:44 UTC
Session pattern
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
Re: [qmf] Session pattern
Posted by Bryan Kearney <bk...@redhat.com>.
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
Re: [qmf] Session pattern
Posted by Gordon Sim <gs...@redhat.com>.
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).
> 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.
>
> Thoughts?
>
> -Ted
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: [qmf] Session pattern
Posted by Ted Ross <tr...@redhat.com>.
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.
Thoughts?
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org