Page History

...

Currently the user's identity is represented by a simple string which contains the user's comon s common name. This gives rise to the possibility that a user with common name fred from one authentication provider is indistinguishable for a fred from another authentication provider.

...

To support more complicate use-cases, it will be desirable to have a group provider that can contribute additional identities to a user's identity based on rules.  This would allow logical expressions to be formed such as 'add identity X if she is already a Y or Z' or 'add identity T if the user is not an S'.  The group provider would produces realm qualified identities too.

We recognised recognise some sources of group information are separate from authentication providers, for instance, the CloudFoundryDashboardManagementGroupProvider.   We have the general notion that a GroupProvider is something capable of contributing additional identities for a user based on identities that already hold.  After authentication, Qpid should interrogate each group provider in turn until no a complete round where additional identities are produced, at which point we will no the Subject is complete.

...

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.

Authentication

We might want to permit authentication where the user passes a realm qualified user name.  This would be useful in the case where the client is not a Qpid client and would other populate the JMSXUserId with the 'wrong' value.

Background Info

Kerberos/Groups

...