[ 
https://issues.apache.org/jira/browse/AXIS2-4493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755449#action_12755449
 ] 

Amila Chinthaka Suriarachchi commented on AXIS2-4493:
-----------------------------------------------------

Can you please attach a patch?

> 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.

Reply via email to