Page History

...

ACL are currently written in terms of common names (user ids or group id) - how would we update existing ACL rules?  We talked about a notion of a default realm to which common names could be assumed to belong if they are not realm qualified.  This might help in the common case where Qpid has one authentication provider.

Open questions

• How does Kerberos handle groups? (see below)
• KW thinks that the ACL parser won't currently like all realm qualified names.  Parse will accept at-sign, dots, but not % sign (which would appear if user ids were URI escaped), equals nor slashes which would appear in an realm using an X500 name.  Perhaps the ACL module needs to change to use quoted names and remove the restrictions on characters appearing within the quotes.
• ACL rules does not distinguish between user and group names.  This means we cannot simply, to aid upgrade, assign an fallback realm to the AccessControlProvider and let it assume that any names without realms belong to the default.

Other issues

Currently the model is completely statically defined. A type (category instance) cannot have a private hierarchy of its own managed objects.  This is pertinent to the  Identity discussion as currently group providers have child and grandchild categories of Group and GroupMember but these only make sense to the group provider implementations that have total knowledge of all the members of a group as a FileGroupProvider.  This is not normally the case. GroupProviders primary role is provide additional identities of the user.  Most GroupProviders won't have the ability to manage the whole group.  We talked about changing the REST API url to be fully hierarchal so that private categories could be accommodated.

...