Andrew, Sorry about the late reply. I've been a bit swamped the past 2 weeks.
On Fri, Apr 16, 2010 at 5:29 AM, Andrew Kennedy <andrewinternatio...@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... Excellent and welcome aboard! Going forward we need to ensure that both brokers support a similar feature set. There are people who are already attempting to use both C++ and Java brokers in a single federated set up. So having similar behaviour and features are crucial for operational folks for maintaining and administering the brokers. > 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. I think for all intents and purposes we should only have a single file format. I think we debated this point and agreed on the current file format. It's not just the c++ file format, but the acl file format for Qpid as well. Also I'd question the value of having an XML based format. Is there a specific reason for this? > additionally, the C++ > file format could be improved, by being stricter with the processing > of continuations and comment lines, In general I'd be keen to hear any thoughts on how we could improve. Could you explain the above point a bit more? > 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 "a...@iterator.co.uk" ALLOW \ > create queue name="adk.*" routingKey="adk" selector="*" > By token you mean the keywords like action, object and property names? If so I am fine with it. > 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. > This is one of the key things I want to tackle on the C++ side as well. There have been requests for this from several users. Specifying the groups in the ACL file is more a convenience than anything else. And we should allow to plug in a 3rd party mechanism in which the ACL file will not contain any group information. Also ACL file is just one way of expressing rules. User should be able to provision acl rules dynamically via QMF. Ted and I have had some discussions about this in the past and I will comment in detail on the JIRA you opened. There is another person who tried to integrate the ACL module with SELinux. > 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 > Check this out http://qpid.apache.org/acl.html Also jonathan and I are working on ACL documentation. I am sure he will contribute that soon. > 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. This is what we do if you try to start up a broker with an invalid ACL file. We also allow to reload an ACL file using QMF. Now in this case if the new ACL file is invalid, 1. The management method will return the error text. 2. the old ACL data will continue to work > 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. The c++ broker also uses it's own pluggin mechanism. > i will also change the actual access checking > from inside the protocol frame handlers to inside the broker entities > themselves. This what the c++ side do as well. > 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. If you plan to add any changes/new features , I'd appreciate we discuss on the list first and ensure that both brokers are consistent in their behaviour. > 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. I will make sure to comment on those JIRA's > cheers, > adk. > -- > -- andrew d kennedy ? edinburgh : +44 7941 197 134 ; > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
