[
https://issues.apache.org/jira/browse/QPID-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7562:
-----------------------------
Description:
QPID-7549 exposed a defect that HTTP threads are not always carrying a Subject.
* We should ensure that HTTP threads always carry a Subject. If the user is not
yet authenticated, this will simple be a Subject containing a
ManagementConnectionPrincipal. If think this is best done once in a filter,
towards the front of the filter chain. The management thread, working on
behalf of the user must also ensure that the task executor subject is not
inherited,.
* Is there a reason why AuthenticationResultCacher should not consider all
SocketConnectionPrincipal rather than just ConnectionPrincipal. I realise that
if Qpid were to be behind a web proxy, then there would be not uniqueness added
(as the end point would be same), but the same argument could be made about
AMQP if it were using a AMQP proxy.
* I think the responsibilities for preemptive authentication and possibly sasl
authentication should be refactored into filters. I think the current code is
hard to follow (separate JIRA).
The simply fix for qpid-java-6.1.x will be carried out under QPID-7549.
was:
QPID-7549 exposed a defect that HTTP threads are not always carrying a Subject.
* We should ensure that HTTP threads always carry a Subject. If the user is not
yet authenticated, this will simple be a Subject containing a
ManagementConnectionPrincipal. If think this is best done once in a filter,
towards the front of the filter chain.
* Is there a reason why AuthenticationResultCacher should not consider all
SocketConnectionPrincipal rather than just ConnectionPrincipal. I realise that
if Qpid were to be behind a web proxy, then there would be not uniqueness added
(as the end point would be same), but the same argument could be made about
AMQP if it were using a AMQP proxy.
* I think the responsibilities for preemptive authentication and possibly sasl
authentication should be refactored into filters. I think the current code is
hard to follow (separate JIRA).
The simply fix for qpid-java-6.1.x will be carried out under QPID-7549.
> Ensure that HTTP threads always carry a ManagementConnectionPrincipal
> ---------------------------------------------------------------------
>
> Key: QPID-7562
> URL: https://issues.apache.org/jira/browse/QPID-7562
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-6.2
>
>
> QPID-7549 exposed a defect that HTTP threads are not always carrying a
> Subject.
> * We should ensure that HTTP threads always carry a Subject. If the user is
> not yet authenticated, this will simple be a Subject containing a
> ManagementConnectionPrincipal. If think this is best done once in a filter,
> towards the front of the filter chain. The management thread, working on
> behalf of the user must also ensure that the task executor subject is not
> inherited,.
> * Is there a reason why AuthenticationResultCacher should not consider all
> SocketConnectionPrincipal rather than just ConnectionPrincipal. I realise
> that if Qpid were to be behind a web proxy, then there would be not
> uniqueness added (as the end point would be same), but the same argument
> could be made about AMQP if it were using a AMQP proxy.
> * I think the responsibilities for preemptive authentication and possibly
> sasl authentication should be refactored into filters. I think the current
> code is hard to follow (separate JIRA).
> The simply fix for qpid-java-6.1.x will be carried out under QPID-7549.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
