Page History

...

•  User identities need to be representable as a string (so that they an be serialised as JSON)
•  The user identity belongs to source identification system. Qpid should be capable of using these identifiers as they stand. It should not invent its own unique user id.
• The identification system may or may not permit an artbitarry arbitrary user identity to resolved into the corresponding human name. For instance, some (LDAP) Directories require that that user authenticates (binds) before that information is returned.
•  The messaging client must contain continue to authenticate using a common name
• We need the ability to group users together for purposes of access control (the admin group etc)
• Some authentication providers are capable of producing group membership information for the authenticated user.  We want to be able to exploit these as a source of groups too.

Ideas

User identity

We discussed the idea of adopting RFC-4120 naming conventions where each common name would be qualified by a realm name:

...

domain: ATHENA.MIT.EDU
X500: C=US/O=OSF
other: NAMETYPE:rest/of.name=without-restrictions

e.g.

keith@ATHENA.MIT.EDU

The AuthenticationProvider would change so that they contribute identities from one or more realms. Some AuthenticationProviders (e.g. Kerberos) would do this 'natively'. For other authentication providers that don't share the same notion, the the user would assign a synthetic realm.  This would mean that all identities within Qpid followed the same realm qualified user identity scheme.

...

The AuthenticationProvider would acquire a responsibility to resolve an arbitrary realm qualified user identity into its human readable name. For some authentication providers, they may be able to perform a live lookup against the identity backend. For others this may be disallowed. To accomodate this case the authentication provider may cache certain details about users as they login, so later, those details can be returned.  This information will allow the operator to know it was Joe Bloggs who created a queue or sent  a message.  This part of the system needs to be aware that some identities may not have human readable names (common in ids used for system to system communication).

Groups

Some authentication providers (such as Directories (LDAP) and Open ID) are able to produce group membership information about the user who is authenticating. For instance, in LDAP a query (&(objectCategory=group)(member=cn=Fletcher Christian,ou=people,o=sevenSeas)) might give cn=HMS Bounty,ou=crews,ou=groups,o=sevenseas.

We need group identities to be unique and belong to the source system in the same was as user identities.  We said we'd adopt the same realm qualified scheme:

admin@ATHENA.MIT.EDU
HMS%20Bounty@o=sevenseas/ou=groups/ou=crews

The subject of the user would comprise its principal representing his user identity and principals representing all of the groups to which he belongs.

The some applications it might be sufficient for ACLs to be expressed in terms of the realm qualified group name produced by the authentication provider i.e. no group provider would be required.

ALLOW admin@ATHENA.MIT.EDU ACCESS BROKER

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 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.

Messaging

The messaging client currently knows only the common name which it used to identify itself to Qpid. It also uses this common name when populating the JMSXUser property in the message header of produced messages. We will want the JMSXUser to be populated with the realm qualified identity.

...

RG: One aspect of this is that all clients  clients will need to behave in a compliant way... which really means we should probably propose something for AMQP 1.0 about how clients should populate fields on the message based on the credentials they authenticated with.

...

Upgrading from older versions

The configuration upgrader should upgrade the authentication providers to have realm (how would we manufacture the realm names). The lastUpdatedBy and createdBy attributes of existing objects and the owner attribute of Queue could be upgraded too in the common case where only one provider is in use.

The store upgrader could apply the same rules and upgrade message headers (it is worth it?)

Some group providers map from common names to group names.

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?

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.

 ACL rules can be written in terms of common names.