Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Queue#owner is affected by this work too

...

  •  Groups are produced by mapping a common name to a group name. Currently we have no way of preventing all fred (a messaging user) from being put in the admins group because there is also fred who is an admin.
  •  The audit trail produced in the log contains only the common name. An action by one fred is indistinguishable from actions of another fred.
  •  The audit attributes of the configured object capture the common name . An queue created by fred carries a createdBy value 'fred'.
  • The owner attribute of Queue also contains a common name.
  •  An application producing a message captures the authenticated identity and records this in the JMSXUserId property of each message. If two applications, using separate AMQP ports using separate authentication provides both have a user called fred, the consuming application has no way to distinguish which fred produced the message.
  •  For messages produced by client authenticating with X-OAuth2 currently have no JMSXUserId. This is because the messaging client is not aware of the authenticated common name
  •  Sometimes common names aren't easily interpretted by a human user. For instance, in the case of Google's OAuth the common name is a 14 digit number. A operator examining using Qpid has no way to discover the human name of the user who performed an action.

...

The configuration upgrader should upgrade the authentication providers to have realm (how would we manufacture the realm names). The lastUpdatedBy and  and createdBy attributes  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.

...