Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Message-ID: <19620167.262631293008171091.JavaMail.jira@thor>
Date: Wed, 22 Dec 2010 03:56:11 -0500 (EST)
From: "Chris Dalrymple (JIRA)" <jira@apache.org>
To: java-dev@axis.apache.org
Subject: [jira] Commented: (RAMPART-240) incomplete SOAP header bypasses
 rampart security
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/RAMPART-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974115#action_12974115 ] 

Chris Dalrymple commented on RAMPART-240:
-----------------------------------------

You have got to be kidding, right? This issue was posted 17/Nov/08. That was over two years ago. Now your answer is that the method is deprecated? With a turnaround like that, this could be your stock answer for everything.

Thanks for getting back to me,
Rip Van Winkle


> incomplete SOAP header bypasses rampart security
> ------------------------------------------------
>
>                 Key: RAMPART-240
>                 URL: https://issues.apache.org/jira/browse/RAMPART-240
>             Project: Rampart
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: eclipse ganymede, Tomcat 6.0.18 running on Windows XP
>            Reporter: Chris Dalrymple
>
> I configured a web service to use basic authentication as demonstrated in basic/example3 of the rampart 1.3 examples. The security works as expected when a request comes in without the necessary SOAP header and the following response is returned:
> [ERROR] WSDoAllReceiver: Incoming message does not contain required Security header
> The security also works as expected when the properly formed SOAP header contains either the wrong username of password. The Callback Handler is invoked and the following response is returned:
> [ERROR] WSDoAllReceiver: security processing failed
> The problem, which I discovered quite by accident, is that a request that is lacking some of the security elements of the SOAP header seems to bypass the Callback Handler completely and give access to the secured resource. Below is an example of a SOAP request that behaves as described.
> <?xml version="1.0" encoding="UTF-8"?>
> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
>       <soapenv:Header>
>             <wsse:Security
>                   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" />
>       </soapenv:Header>
>       <soapenv:Body>
>             <ns1:getUnitId xmlns:ns1="http://axis2.webservice.lsu.edu">
>                   <ns1:unitId>b3Z76yu439156</ns1:unitId>
>             </ns1:getUnitId>
>       </soapenv:Body>
> </soapenv:Envelope>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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