[
https://issues.apache.org/jira/browse/AXIS2-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681628#action_12681628
]
Nandana Mihindukulasooriya commented on AXIS2-4233:
---------------------------------------------------
Hi Alexis,
I think the behavior that was there in 1.3 is correct and if the
service is dispatched we need to take that in to account when calculating the
effective policy. To avoid security vulnerabilities, we will need to improve
the PostDispatch verification handler of Rampart to check the policy after
dispatch (both service and operation) and the policy that was used to verify
security to see whether there are identical.
The work around you proposed works in this scenario but may cause
problems in other scenarios. When RampartMessageData.KEY_RAMPART_POLICY is set,
Rampart only takes that policy in to account so policies set in other levels of
the heirachy will be ignored.
thanks,
Nandana
> Regression in MessageContext#getEffectivePolicy between 1.3 and 1.4/1.5
> -----------------------------------------------------------------------
>
> Key: AXIS2-4233
> URL: https://issues.apache.org/jira/browse/AXIS2-4233
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5, 1.4.1, 1.4
> Reporter: Alexis Midon
> Priority: Blocker
>
> Here is the use case:
> A security policy is attached to my service (using a service.xml document and
> a ServiceBuilder).
> A message comes in, and reaches the RampartReceiver. At this point *only* the
> targeted service has been resolved by the preceding dispatchers, so no
> operation nor AxisMessage [4] are attached to the MessageContext yet .
> Actually the information required to resolve the operation is encrypted. So
> the MessageContext knows about the service *only*.
> Then the RampartReceiver tries to get the policy to be applied. This is done
> in RampartMessageData. To do that, MessageContext#getEffectivePolicy is
> invoked.
> In axis2 1.3, MessageContext#getEffectivePolicy [1] has a logic to retrieve
> the policy from the service instance. But in axis2 1.4 [2], the logic is
> different and never tries to get the policy from the service. So Rampart
> cannot do its job, and my service invocation fails :(
> To get the effective policy, the current implementation of
> MessageContext#getEffectivePolicy uses an instance of AxisBindingMessage if
> any. But AxisBindingMessage also requires the operation to be known [5] So I
> cannot workaround my problem, afaik.
> It seems that this issue has already been spotted [3] but I haven't found any
> related Jiras. And the regression is still in 1.5.
> A fix for axis2 1.5 will be really helpful.
> [1]
> http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.3/modules/kernel/src/org/apache/axis2/context/MessageContext.java
> [2]
> http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.4.1/modules/kernel/src/org/apache/axis2/context/MessageContext.java
> [3] http://markmail.org/thread/ghsdxqdwnhec7puo
> [4] line 114,
> http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.4.1/modules/kernel/src/org/apache/axis2/engine/AbstractDispatcher.java
> [5] line 275,
> http://svn.apache.org/repos/asf/webservices/axis2/tags/java/v1.4.1/modules/kernel/src/org/apache/axis2/description/AxisBindingMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
