qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: JavaBroker v2 ACLs (QPID-2476)
Date Fri, 23 Apr 2010 15:01:53 GMT
On Fri, Apr 16, 2010 at 10:29 AM, Andrew Kennedy <
andrewinternational@gmail.com> wrote:

> hi.
> 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.
> I think splitting out groups and ACL from the one file would be a good
thing, I don't see why we'd maintain them in the same place. I don't know
how the groups are used (aside from ACLs) in the C++ broker though ? Groups
would often be anticipated to come from another source, ideally, to negate
the need to maintain multiple user credentials.

> 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:
>    http://qpid.apache.org/acl.html#ACL-userguide
Be good know what the set of use cases we support is - I couldn't spot that

> 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).

Can you doc the error codes to be used on the JIRA pls and I'll take a look
? Thx.

> 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.

1. definitely best - they can after all opt to have no ACLs if they like,
but invalid ACLs are probably always a hard fail case.

>    2. record the error and start the broker with a best effort at
> parsing the file, ignoring the rule (and possibly even all following
> rules).
>    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.
> What access routes to the C++ broker are currently controlled from the ACLs

> 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.
> Thanks, will take a look at the JIRA too.


> cheers,
> adk.
> --
> -- 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message