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. thanks, dims On Tue, Jul 1, 2008 at 2:48 AM, Sanka Samaranayake <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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. > > http://sankas.blogspot.com/ > http://www.wso2.org/ -- Davanum Srinivas :: http://davanum.wordpress.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
