qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject JavaBroker v2 ACLs (QPID-2476)
Date Fri, 16 Apr 2010 09:29:39 GMT

i am going to be implementing QPID-2476, version 2 access control
lists for the Java broker. these are my current thoughts and i would
appreciate any ideas or caveats, but please bear in mind that i am new
to the Qpid code-base, and may be going over material that has already
been discussed or conclusions already reached, although i couldn't
find much in the list archives...

at the moment i am going to simply port the C++ file format to Java,
and access it from the existing XML configuration via a link to a
separate file, but i think the ACLs should also be expressible as a
pure XML configuration, to be documented later. additionally, the C++
file format could be improved, by being stricter with the processing
of continuations and comment lines, and i see no reason for the tokens
to be case sensitive. quoting of identifiers would be a useful
addition, allowing syntax such as:

    ACL "adk@iterator.co.uk" ALLOW \
        create queue name="adk.*" routingKey="adk" selector="*"

perhaps also splitting group configuration and ACL configuration into
separate files, since these are obviously quite different things, and
it is foreseeable that groups would be desirable to load via an
external authentication or directory service.

a proper description of the meaning of ACL rules is also required,
since it is not always clear what the intent of rules and ordering
might be. the only documentation i could find is here:


i will try and use the same error text as the C++ parser, but these
should probably be standardised somewhere (again, i may just not have
been able to find this). also, error recovery is not very well defined
- i would be interested to know what people's position is on broker
behavior with invalid or badly-formed ACL configurations. there are a
few possibilities:

    1. exit the broker immediately with an exception.
    2. record the error and start the broker with a best effort at
parsing the file, ignoring the rule (and possibly even all following
    3. record the error and start the broker with an empty ACL
configuration that ALLOWS all access.
    4. record the error and start the broker with an empty ACL
configuration that DENIES all access.

i believe 2 is desirable, but 1 is easiest. depending on requirements,
3 or 4 could be configurable behaviours after errors.

as regards the mechanics of the implementation, i will use the
existing plugin architecture, and eventually a proper OSGi plugin
would be desirable, particularly when interacting with other plugins
for SSO, kerberos et al. i will also change the actual access checking
from inside the protocol frame handlers to inside the broker entities
themselves. this will allow a single set of ACLs to control the broker
no matter how it is accessed - by AMQP client, JMS, JMX or QMF. i will
also be adding extra objects that can have ACLs, such as the
administration of users and logs, and will need to determine how much
of a performance impact ACL processing incurs, particularly for
publishing and consuming messages, and whether some form of cache
strategy will be necessary.

i will be updating the QPID-2476 issue with some sub-tasks to reflect
the text above and also adding some design documentation in due
course, but would still appreciate any comments so far.

-- andrew d kennedy ? edinburgh : +44 7941 197 134 ;

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

View raw message