Andrew, since you have already opened several JIRA's focused on specific areas, lets continue the discussion there.
On Tue, Apr 27, 2010 at 5:39 AM, Andrew Kennedy <[email protected]> wrote: > On 23 April 2010 16:01, Marnie McCormack > <[email protected]> wrote: >> On Fri, Apr 16, 2010 at 10:29 AM, Andrew Kennedy >> <[email protected]> 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:[email protected] > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/ --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
