axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lahiru Sandakith" <sandak...@gmail.com>
Subject Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4)
Date Wed, 09 Jul 2008 11:55:33 GMT
+1 for Nandana as the Release Manager

Regards
Lahiru Sandakith

On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas <davanum@gmail.com> wrote:

> Nandana,
>
> +1 from me for you to be the Release Manager for 1.4.1
>
> IMHO, we should use 1.4 branch. The *ONLY* change should be the
> security change. Nothing more.
>
> thanks,
> dims
>
> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya
> <nandana.cse@gmail.com> wrote:
> > I would like to volunteer to be the release manager for Axis2 1.4.1.
> >
> > I think we can fix the critical issues in the 1.4 branch (or a 1.4.1
> branch
> > ) and do the 1.4.1 release. I don't think doing 1.4.1 from the trunk is
> the
> > appropriate way as trunk is now java 1.5 and has lot of major changes
> after
> > Axis2 1.4 . However we can fix any issues that are not already fixed in
> the
> > trunk at the same time when we fix those in the branch.
> >
> > Hope this is oky with Axis2 release guidelines.
> >
> > thanks,
> > nandana
> >
> > On Tue, Jul 1, 2008 at 6:39 PM, Davanum Srinivas <davanum@gmail.com>
> wrote:
> >>
> >> 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 <ssanka@gmail.com>
> >> 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
> >> > <nandana.cse@gmail.com> 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: axis-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: axis-dev-help@ws.apache.org
> >>
> >
>
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>


-- 
Thanks
Lahiru Sandakith

http://sandakith.wordpress.com/
GPG Key Fingerprint : 8CD8 68E0 4CBC 75CB 25BC 1AB1 FE5E 7464 1F01 9A0F

Mime
View raw message