axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <>
Subject Re: Security hole in Axis2 1.4 + Rampart 1.4
Date Tue, 01 Jul 2008 13:09:04 GMT
IMHO, The logic is the same as for blockers. If there is a work
around, it's not a blocker. So i am +0 on a 1.4.1 since there is a
work around that can be documented.

That said, If someone is willing to drive a 1.4.1 as the release
manager, please do go ahead.


On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake <> wrote:
> Hi,
> For the users who is already using 1.4 version, the workaround would be to
> define policies in services.xml without using <wsa:PolicyAttachment>. Then
> the problem is that those policies will appear in <wsdl:PortType> which is
> not correct but security will apply for both format of service URLs.
> Hence +1 for fixing that issue and do 1.4.1 release.
> Thanks,
> Sanka
> On Mon, Jun 30, 2008 at 8:59 PM, Nandana Mihindukulasooriya
> <> wrote:
>> Hi,
>>    There are few issues with Axis2 1.4 / Rampart 1.4 with the new policy
>> configuration. The new policy configuration which allows us to apply
>> policies to binding hierarchy is a great feature when in comes to ws
>> security policy configuration. It allows security policies to be attached to
>> the correct attachment points. But there are few issues that need to be
>> fixed in Axis2 1.4. I will list them below.
>>     1.) If we configure security using new configuration, service can be
>> accessed without security.
>>          In Axis2 1.4, a service is exposed in two EPRs (consider SOAP 1.1
>> binding).
>>            eg.
>> http://localhost:8080/axis2/services/SecureService.SecureServiceHttpSoap11Endpoint
>>                http://localhost:8080/axis2/services/SecureService
>>           But if we you set the policies using the new configuration, if
>> you do a web service call to the older EPR, you can access the service
>> without any security even though it is secured using the binding hierarchy.
>> This happens because if we call the old EPR, it is not dispatched to a
>> binding. But this leaves the service vulnerable. I think we should dispatch
>> to one of the bindings may be using soap envelope version if we have only
>> one binding with that soap version. We should have a way to dispatch
>> messages which comes to old EPR to one of the bindings else we should have
>> an option to disable that EPR.
>>     2.) In the out flow, policies are not set correctly in the binding
>> message.
>>           This is fixed in the trunk but this bug is there in Axis2 1.4.
>>    So the option we have is to configure security using the old
>> configuration. But then the problem is policies are attached to the port
>> type which is the correct way to do if we have policies using
>> <service>,<operation><message> tags. But this makes Axis2 not interoperable
>> as security policies should be attached to binding hierarchy according WS
>> Security policy specification. Ideally we should always use the new
>> configuration to apply security. And code generation also doesn't work
>> correctly when the policies attached to the port type (polices are not
>> correctly attached to the stub).
>>    So I think it would be great if can consider a Axis2 1.4.1 with these
>> things fixed.
>> thanks,
>> nandana
> --
> Sanka Samaranayake
> WSO2 Inc.

Davanum Srinivas ::

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message