[
https://issues.apache.org/jira/browse/AXIS2-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755453#action_12755453
]
Detelin Yordanov commented on AXIS2-4493:
-----------------------------------------
I will, but are you sure this fix won't cause any backward incompatibility
issues?
> Disengagement of module which is not globally engaged removes module's
> handlers from the global phase chain
> -----------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-4493
> URL: https://issues.apache.org/jira/browse/AXIS2-4493
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.5
> Environment: Tomcat 5.5.26, Axis2 war 1.4.1/1.5, Rampart 1.4
> Reporter: Detelin Yordanov
> Attachments: patch.txt, ut-secured-service1.aar,
> ut-secured-service1.zip, ut-secured-service2.aar
>
>
> We have an Axis2 1.4.1 runtime, which has Rampart module deployed, but not
> globally engaged (using the default axis2.xml from axis2.war)
> We have two services, both of them are secured (Rampart is engaged for each
> service by using <module ref="rampart"/> in services.xml).
> When Rampart is disengaged on one of the services, it happens that the
> Rampart handler is removed from the security phase. This practically disables
> access to the other secured service, since secured service requests are not
> handled by Rampart anymore (no handler in security phase) and when attempting
> to invoke it, Axis2 throws a mustUnderstand check failed for the security
> header:
> [ERROR] Must Understand check failed for header
> http://docs.oasis-open.org/wss/
> 004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd : Security
> We examined the module disengage logic, and it seems that the handler removal
> takes place in AxisOperation#onDisengage(AxisModule module). The code there
> would remove module's handlers from global chains if the module is not
> engaged on service nor on gloabal level. What is the reason for this, and
> what if the module is engaged on another service (as in our case)?
> I attach two simple services you can simulate this with. They are based on
> Rampart's Tomcat policy sample, but are secured
> with a simple Username supporting token.
> Steps to simulate the problem:
> 1. Deploy both services to Axis2 1.4.1/1.5 webapp having Rampart deployed
> (but not engaged in axis2.xml)
> 2. Using the web administration intefrace, disengage Rampart module on one of
> the services
> 3. Try to invoke the other service using the Client.java class (or by any
> other means)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
