On Fri, Apr 16, 2010 at 10:29 AM, Andrew Kennedy < [email protected]> 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 "[email protected]" 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. Regards, Marnie > cheers, > adk. > -- > -- andrew d kennedy ? edinburgh : +44 7941 197 134 ; > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
