Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 76139 invoked from network); 11 Jul 2008 09:20:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Jul 2008 09:20:29 -0000 Received: (qmail 49088 invoked by uid 500); 11 Jul 2008 09:20:28 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 48612 invoked by uid 500); 11 Jul 2008 09:20:26 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 48601 invoked by uid 99); 11 Jul 2008 09:20:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Jul 2008 02:20:26 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of amilasuriarachchi@gmail.com designates 74.125.46.154 as permitted sender) Received: from [74.125.46.154] (HELO yw-out-1718.google.com) (74.125.46.154) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Jul 2008 09:19:30 +0000 Received: by yw-out-1718.google.com with SMTP id 6so1639373ywa.88 for ; Fri, 11 Jul 2008 02:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=JirX9hSuc1dUK2GlcgHGrCN22DQ5RT+Jrte26GJYKHg=; b=JMn3iwD6Ip1ulp3u9rTCEiXtH3jWxXYQO3taPhlYAZnphLMgYcQYdCKTSDld4WJpgF 6PgTS8Gv43nhR7lt5RqoAYjvIsu1FvFek5d/ULdPS3aWrA+f4Gfqjn6OnM3OK4B0qkOT hFQLQx718oh+eLbt4730U0tdx+J53rDJ8np/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Yk7NWXTd6hT2vNU2qCExU04gI9UlX394hs0eKBSjjsCRe/d+t2Nd0xI0fF1QHcQXRk y0HXSAV4rXtqc3+0QJaS7QMbZCHtrM+Kh1XVNDVsV3QrH5b1po37AHZakYPYRU5w8no6 dTeQLD/O0TgLOxZ9o5+YplLUsuGTnA1cTX+Is= Received: by 10.151.145.17 with SMTP id x17mr15536659ybn.102.1215767967608; Fri, 11 Jul 2008 02:19:27 -0700 (PDT) Received: by 10.151.7.8 with HTTP; Fri, 11 Jul 2008 02:19:27 -0700 (PDT) Message-ID: <60708f4b0807110219l2172033bx2306cae08ff3b99d@mail.gmail.com> Date: Fri, 11 Jul 2008 14:49:27 +0530 From: "Amila Suriarachchi" To: axis-dev@ws.apache.org Subject: Re: [Axis2][1.4.1] Nandana as Release Manager (Re: Security hole in Axis2 1.4 + Rampart 1.4) In-Reply-To: <1e8c1ed40807082110k5a1561d3x9d9bd4c5c2d7abb0@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_22080_7048891.1215767967536" References: <19e0530f0807070533o38485e27kc5b60511386000a1@mail.gmail.com> <60708f4b0807070609id1d6786w9ee73c00aee2fae4@mail.gmail.com> <4872160B.1080601@gmail.com> <48721B37.1060208@thoughtcraft.com> <9e2fff830807070709v5d403428s773cf22e9511cda1@mail.gmail.com> <1e8c1ed40807082110k5a1561d3x9d9bd4c5c2d7abb0@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_22080_7048891.1215767967536 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wed, Jul 9, 2008 at 9:40 AM, Sanka Samaranayake wrote: > > > On Mon, Jul 7, 2008 at 7:39 PM, Nandana Mihindukulasooriya < > nandana.cse@gmail.com> wrote: > >> Hi Glen, >> >> - Let's aim to get 1.4.1 out the door at the end of next week, i.e. July >>> 18th (is that enough time, Nandana?). >> >> >> I think we have to check Sanka's input on this. He will be fixing the >> major issue in policy. >> > > > IMO, proper fix would be to improve Axis2 Dispatchers to set the > AxisBindings in the MessageContext during the dispatch phase based on > properties of incoming message even if client request came to the old format > of service URL. For example for a message that came to older format of the > service URL, the Dispatches can decide whether it belongs to the SOAP11 or > SOAP12 or HTTP binding based on envelope namespace URI and content type . > That way effective policy calculation will always happen based on the > AxisBindings which will ensure the application of security irrespective of > the format of service URL. > Seems to be good. What happens, 1. There is not SOAP 11Binding for a SOAP 11 message 2. There are two SOAP 11 Bindings for a SOAP 11 message. I think in both cases we have to throw an exception. thanks, Amila. > > > Thanks, > Sanka > > > > > >> >> >> - As always it's good to go through at least one RC so people can kick >>> the tires, check the artifacts, etc. So let's aim to get the RC out by >>> Tuesday the 15th. >> >> >> +1 for the RC. >> >> thanks, >> nandana >> >> Davanum Srinivas wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Exactly what i was afraid of :( Sigh! this is a *very* slippery slope. >>>> >>>> - -- dims >>>> >>>> Amila Suriarachchi wrote: >>>> | On Mon, Jul 7, 2008 at 6:03 PM, Davanum Srinivas >>>> wrote: >>>> | >>>> |> Nandana, >>>> |> >>>> |> +1 from me for you to be the Release Manager for 1.4.1 >>>> | >>>> | >>>> | + 1 from me. >>>> | >>>> |> >>>> |> IMHO, we should use 1.4 branch. The *ONLY* change should be the >>>> |> security change. Nothing more. >>>> | >>>> | I think we need to fix any possible other critical issues as well. >>>> | eg. https://issues.apache.org/jira/browse/AXIS2-3870 >>>> | This is a memory leak and we need to fix this. >>>> | >>>> | thanks, >>>> | Amila. >>>> | >>>> | >>>> | >>>> |> >>>> |> thanks, >>>> |> dims >>>> |> >>>> |> On Mon, Jul 7, 2008 at 6:50 AM, Nandana Mihindukulasooriya >>>> |> 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 >>> > >>>> |> 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 >>>> . >>>> |>>>> Then >>>> |>>>> the problem is that those policies will appear in >>>> |> 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 >>>> |>>>>> , 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 >>>> |> >>>> |> >>>> | >>>> | >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.6 (GNU/Linux) >>>> >>>> iD8DBQFIchYLgNg6eWEDv1kRAo7lAKDKyTiR50/aWOSuc9d7pVPHQPUoeACgkg+A >>>> sQpm1+6vbyVf0CMQkT1aYXI= >>>> =hpVj >>>> -----END PGP SIGNATURE----- >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org >>>> For additional commands, e-mail: axis-dev-help@ws.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org >>> For additional commands, e-mail: axis-dev-help@ws.apache.org >>> >>> > > > -- > Sanka Samaranayake > WSO2 Inc. > > http://sankas.blogspot.com/ > http://www.wso2.org/ > -- Amila Suriarachchi, WSO2 Inc. ------=_Part_22080_7048891.1215767967536 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On Wed, Jul 9, 2008 at 9:40 AM, Sanka Samaranayake <ssanka@gmail.com> wrote:


On Mon, Jul 7, 2008 at 7:39 PM, Nandana Mihindukulasooriya <nandana.cse@gmail.com> wrote:
Hi Glen,

- Let's aim to get 1.4.1 out the door at the end of next week, i.e. July 18th (is that enough time, Nandana?).

I  think we have to check Sanka's input on this. He will be fixing the major issue in policy.


IMO, proper fix would be to improve Axis2 Dispatchers to set the AxisBindings in the MessageContext during the dispatch phase based on properties of incoming message even if client request came to the old format of service URL. For example for a message that came to older format of the service URL, the Dispatches can decide whether it belongs to the SOAP11 or SOAP12 or HTTP binding based on envelope namespace URI and content type . That way effective policy calculation will always happen based on the AxisBindings which will ensure the application of security irrespective of the format of service URL.

Seems to be good. What happens,
1. There is not SOAP 11Binding for a SOAP 11 message
2. There are two SOAP 11 Bindings for a SOAP 11 message.

I think in both cases we have to throw an exception.

thanks,
Amila.


Thanks,
Sanka



 


- As always it's good to go through at least one RC so people can kick the tires, check the artifacts, etc.  So let's aim to get the RC out by Tuesday the 15th.
 
+1 for the RC.

thanks,
nandana

Davanum Srinivas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Exactly what i was afraid of :( Sigh! this is a *very* slippery slope.

- -- dims

Amila Suriarachchi wrote:
| 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
|
|
| + 1 from me.
|
|>
|> IMHO, we should use 1.4 branch. The *ONLY* change should be the
|> security change. Nothing more.
|
| I think we need to fix any possible other critical issues as well.
| eg. https://issues.apache.org/jira/browse/AXIS2-3870
| This is a memory leak and we need to fix this.
|
| thanks,
| Amila.
|
|
|
|>
|> 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
|>
|>
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIchYLgNg6eWEDv1kRAo7lAKDKyTiR50/aWOSuc9d7pVPHQPUoeACgkg+A
sQpm1+6vbyVf0CMQkT1aYXI=
=hpVj
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org




--



--
Amila Suriarachchi,
WSO2 Inc. ------=_Part_22080_7048891.1215767967536--