ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: Apache Rampart test failure with wss4j 1.6.5 and later
Date Tue, 08 Jul 2014 15:39:13 GMT
I keep getting these "Could not find file
.../target/artifacts/addressing-1.6.3-SNAPSHOT.mar to copy" type errors on
the 1.6.x branch. How do I work around this?

Colm.


On Tue, Jul 8, 2014 at 4:21 PM, <detelinyordanov@gmail.com> wrote:

> 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
>>
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Mime
View raw message