ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From detelinyorda...@gmail.com
Subject Re: Apache Rampart test failure with wss4j 1.6.5 and later
Date Tue, 08 Jul 2014 15:21:21 GMT
Hi Colm,
  What I did so far is to checkout Rampart (I have tried both trunk and 1.6
branches), increase the wss4j dependency to 1.6.5 and run "mvn clean
package -Dtest=RampartTest". This fails on the "Testing WS-Sec: custom
scenario 7" with the error I described. Switching the dependency back to
1.6.4 fixes this issue, but still there is one additional scenario (28)
which is failing, however I presume it is not related with wss4j but
probably with Axiom.

I have checked out wss4j 1.6.x branch and build it locally, then switched
Rampart to this version and re-executed the tests. The tests succeeded up
until the point I switched to wss4j revision 1294114. With previous 1294094
revision, this scenario is working fine.

I was thinking it might be related with changes of other dependencies, but
I doubt this is the case, since this revision does not introduce dependency
changes.

I will continue with the investigation and let you know once I have more
information.

Thanks,
   Detelin


On Tue, Jul 8, 2014 at 4:51 PM, Colm O hEigeartaigh <coheigea@apache.org>
wrote:

>
> Are you sure that the commit you referenced above is causing the problem?
> Rampart trunk fails on that test for me with WSS4J 1.6.4. Rampart 1.6.x
> branch fails on something else...
>
> If you have time to look into it, you could try checking out that SNAPSHOT
> version of WSS4J (Before the commit) + check that it works + then apply
> each change and see what change causes the failure. Ultimately, it looks
> like Rampart might be at fault, as the response message is not composed
> properly
>
> Colm.
>
>
> On Tue, Jul 8, 2014 at 12:55 PM, <detelinyordanov@gmail.com> wrote:
>
>> Hi everyone,
>>    Our team worked on new functionality that is to be released with
>> upcoming wss4j 1.6.16 (WSS-500
>> <https://issues.apache.org/jira/browse/WSS-500> & WSS-501
>> <https://issues.apache.org/jira/browse/WSS-501>). We have managed to
>> integrate this functionality within Apache Rampart 1.6.2 and are willing to
>> contribute the necessary pieces there as well. However, so far we have been
>> using wss4j 1.6.4 + the corresponding patches and they seem to work fine
>> with Rampart 1.6.2.
>> Once I saw the vote for releasing wss4j 1.6.16, I decided to try to build
>> Rampart 1.6.2 against it, just to make sure it can adopt this new version
>> in near future.
>> However, I stumbled upon a test failure in Rampart integration module,
>> which I managed to track down to a specific commit in wss4j. The commit is
>> quite old, it is released in wss4j 1.6.5 (latest Rampart uses 1.6.4). The
>> change that causes trouble is the following:
>>
>> http://svn.apache.org/viewvc?view=revision&revision=1294114
>>
>> Log message says "Only decrypt a Data Reference in the
>> ReferenceListProcessor, if it hasn't already been decrypted by the
>> EncryptedDataProcessor".
>>
>> The specific Rampart test that fails is
>> "org.apache.rampart.RampartTest#testWithPolicy()" using the following
>> security policy:
>>
>>
>> http://svn.apache.org/repos/asf/axis/axis2/java/rampart/trunk/modules/rampart-integration/src/test/resources/rampart/policy/7.xml
>>
>> I'm attaching the SOAP request and response (request.xml and
>> response.xml), the actual error message is on the client side, when
>> processing the response from the service:
>> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
>>     at java.lang.String.charAt(String.java:658)
>>     at org.apache.ws.security.WSDocInfo.getResult(WSDocInfo.java:225)
>>     at
>> org.apache.ws.security.str.DerivedKeyTokenSTRParser.parseSecurityTokenReference(DerivedKeyTokenSTRParser.java:90)
>>     at
>> org.apache.ws.security.processor.DerivedKeyTokenProcessor.handleToken(DerivedKeyTokenProcessor.java:53)
>>     at
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:398)
>>     at
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:304)
>>     at
>> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:249)
>>     at org.apache.rampart.RampartEngine.process(RampartEngine.java:147)
>>
>> The stack trace is generated using wss4j revision 1294114.
>>
>> It can be seen that the response contains invalid references (URI not
>> correctly set):
>>
>> <wsse:SecurityTokenReference ...
>> wsu:Id="STR-AA4ACE8415228CCC8E140481886870110">
>>     <wsse:Reference URI="#"  ValueType="
>> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey"
>> />
>> </wsse:SecurityTokenReference>
>>
>> I'm now trying to figure out what is the root cause of this and whether
>> the problem is on the wss4j side or on Rampart's side, but I would be glad
>> if anyone more experienced takes a look into this and provides some
>> feedback.
>>
>> Thanks!
>>
>>    Detelin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: dev-help@ws.apache.org
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>

Mime
View raw message