On 23 April 2010 16:01, Marnie McCormack <marnie.mccorm...@googlemail.com> wrote: > On Fri, Apr 16, 2010 at 10:29 AM, Andrew Kennedy > <andrewinternatio...@gmail.com> wrote: > >> hi. >> >> 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.
the changes i am suggesting for the acl file format are fairly minor, to be honest, and i will expand on this in a later message. i also agree with all the points made on-list about group definitions. there are several mechanisms available for accessing group and role informastion, such as the basic unix /etc file format, microsoft active directory or plain LDAP or JNDI. Also, proprietary SSO systems, or mechanisms like siteminder or perhaps links to a kerberos authentication system could be used. this would function with a pluggable group access module, similar to the ACL and authentication modules. the plugin would need to allow verification of an authenticated principal's membership in a group. this could be achieved at initial authentication, however for long-lived connections this might cause problems if group memberships are changed to add permissions mwhile the broker is running. the plugin could integrate with an authenticationm mechanism and share code and configuration, simply offering an extra interface via a new group access API. in fact, the authentication code provides a good model for implementation of different group access mechanisms. the api for the plugin must, at minimum support a method that checks if a given user is a member of a particular group name: boolean checkMembership(String userName, String groupName); examples of plugin classes would be: org.apache.qpid.server.security.groups.plugin.UnixFile org.apache.qpid.server.security.groups.plugin.ActiveDirectory org.apache.qpid.server.security.groups.plugin.LDAPServer org.apache.qpid.server.security.groups.plugin.JNDIServer 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
