axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley" <>
Subject Re: Security hole in Axis2 1.4 + Rampart 1.4
Date Mon, 30 Jun 2008 16:50:20 GMT
Ouch. That's really not good.

+1 for a 1.4.1


On Mon, Jun 30, 2008 at 4:29 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

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

View raw message