[rabbitmq-discuss] AMQP security / dealing with Flex subscribers

[Ben Hood]

Joern,

On Fri, Jan 23, 2009 at 9:29 AM, Joern <opendev at gmail.com> wrote:
> I wonder if the following would be an alternative for fine-granular,
> application-specific access control logic.
>
>  - Users are getting additional flags: 'untrusted' and 'trusted'.
>  - Every action (binding, declaring, sending messages) of an
> 'untrusted' user is replicated as a message (in some easy to digest
> format) to an access control system exchange.
>  - Access control applications bind queues to this exchange and reply
> with 'grant' or 'deny' (with configurable timeouts) or do other things
> like logging / accounting. The results of an authorization reply may
> be cached, depending on the reply of the access control application.
> The cache can be flushed by access control applications and is
> specific to the individual access control application and/or user in
> question. The applications need 'trusted' users in order to bind to /
> send messages to this system exchange.

Maybe you could get away without needing to build in an explicit
grant/deny request/response cycle and having to differentiate between
trusted and untrusted users.

If you published the name of an exchange to the public, you could have
a security aware consumer process these messages and then forward them
to the real exchange, which would have an unguessable name that only
this consumer knows about.

This consumer could perform any logic that that it wants to.

BTW this is similar to the capabilities concept I described yesterday
- did you read the article?

HTH,

Ben