[
https://issues.apache.org/jira/browse/QPID-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12633439#action_12633439
]
Rajith Attapattu commented on QPID-943:
---------------------------------------
Carl,
I had a brief chat with ted on irc and we have the following solutions for the
above issue.
1 Trusted broker federation
--------------------------------------
Implement single-sign-on to a federation.
So when a client logs into a broker thats part of a trusted federation, it will
also receive a ticket.
This ticket will be included in the message properties. The other broker will
skip the user id check if a valid ticket is available.
A client trying to fake a ticket (similar to trying to fake a keberos ticket)
will depend on the strength of mechanism we use for our single-sign-on solution.
2. Running Federation with user_id check turned off, but protecting the ability
to do so with ACL
----------------------------------------------------------------------------------------------------------------------------------
If you are running in an untrusted domain then you could turn off the user_id
check for federation links.
Currently the user_id check is global, but we could also make this connection
specific and the ability to turn it off controled via ACL's.
The request to turn off user_id check can be a qpid specific parameter in the
arguments passed in connection start.
This way we can turn the user_id check on/off for selectively on a per
connection basis.
Comments and suggestions are most welcomed.
Regards,
Rajith.
> 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: 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.
