[
https://issues.apache.org/jira/browse/QPID-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633578#action_12633578
]
Gordon Sim commented on QPID-943:
---------------------------------
Regarding the interaction of userid checking with federation, I think a
variation on option (2) above is probably a reasonable short term solution.
Here an inter-broker link would be identified by a capability or property
communicated during the connection establishment and for inter-broker links,
since the transfer would have been verified by the broker which initially
accepted the transfer, subsequent checking would be ignored. Establishing an
inter-broker link would then be an action that could be enforce via permissions
in an ACL. (I.e. the only difference wrt (2) above is that the apabaility and
permission is more generic than turning off userid checking).
A slightly more involved feature would be to grant permission (through the ACL)
for an authenticated user to 'send on behalf of' a specific set of other users
(which could be 'all users').
I am not at all keen on the command line option to disable userid validation;
if authorisation is on and a userid is specified by the client, I think its
better to always validate it. In the future perhaps permission to publish
anonymous messages (where no userid is specified) might be grantable through
the ACL, for now I suspect that client side configuration is sufficient here.
[Other specific change requests on c++ patch sent to author].
> Move JMSXUserID creation to client to improve broker performance
> ----------------------------------------------------------------
>
> Key: QPID-943
> URL: https://issues.apache.org/jira/browse/QPID-943
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker, Java Client
> Affects Versions: M2.1
> Reporter: Marnie McCormack
> Assignee: Rajith Attapattu
> Fix For: M4
>
> Attachments: javabroker_userid_check.patch, JMSXUserID.patch,
> userid_check.patch
>
>
> Summary:
> Currently the broker modifies the message to add the JMSXUserID. A better
> approach would be to have the client encode that detail and have the broker
> verify that it is correct. This means that the broker does not have to
> re-encode every message. It also allows the sending client to decide if they
> wish to include the JMSXUserID for validation.
> Proposed Changes:
> Removing existing modification code replacing with validation if the
> JMSXUserID is present. If validation is required to pass then close the
> connection on failures.
> Augment to client to have the ability to manuall or automatically set the
> JMSXUserID based on the authenticated connection.
> Test Strategy:
> Test messages with manual user id creation(correct and incorrect), automatic
> user id creation.
> Test broker in validation mode and lenient mode.
> Testing should include performance metrics to quantify the inpact of the
> additional processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
