I can open a defect in Rampart, but I'm not sure what should be the
proposed change there - I was thinking that it can check for empty id tag
and skip the result, but if wss4j does not generate results with empty id
anymore, this will not be required. Rampart uses the following code to
identify the encryption key id from the request, for which a response in
generated:
for (WSSecurityEngineResult wsSecEngineResult : wsSecEngineResults) {
Integer actInt = (Integer)
wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
String encrKeyId = (String)
wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
if (actInt == WSConstants.ENCR && encrKeyId != null) {
return encrKeyId;
}
}
If you think the above is improper or can be improved, just let me know and
I will follow up with Rampart devs.
Detelin
On Wed, Jul 9, 2014 at 12:45 PM, Colm O hEigeartaigh <[email protected]>
wrote:
>
> Thanks for the investigation. It turns out Maven 3.0.x is required to
> build Rampart.
>
> I've merged a "fix" for this issue in WSS4J, where we don't store the
> token Id if it is an empty String. IMO Rampart should also be fixed.
>
> Colm.
>
>
> On Tue, Jul 8, 2014 at 6:03 PM, <[email protected]> wrote:
>
>> I have not seen these, probably it is the "copy-mars" execution in the
>> integration module that is causing them. It could be some dependency
>> resolution problem for "mar" artifacts, I'm using Maven 3.0.4 and did not
>> experience such issues.
>>
>> I have some more input on the problem - I think that the introduction of
>> an "id" tag for reference list results is confusing Rampart, specifically
>> the first change here:
>>
>>
>> http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/main/java/org/apache/ws/security/processor/ReferenceListProcessor.java?r1=1294114&r2=1294113&pathrev=1294114
>>
>> In the example request that I attached, there is a ReferenceList element
>> that looks like this:
>>
>> <xenc:ReferenceList
>> xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";><xenc:DataReference
>> URI="#ED-5"/></xenc:ReferenceList>
>>
>> When processing this, the ReferenceListProcessor with the mentioned
>> change now creates a result instance, but with an empty "id" tag, since the
>> ReferenceList element does not have "Id" attribute. The result object looks
>> like this:
>>
>> {id=, data-ref-uris=[org.apache.ws.security.WSDataRef@3e9c6879],
>> action=4, validated-token=false}
>>
>> When generating the response, Rampart's AssymetricBindingBuilder searches
>> for the encrypted key by iterating over the results list and checking for a
>> result with action=4 (ENCR) and a non-empty id tag, see
>> AsymmetricBindingBuilder.setupEncryptedKey and
>> RampartUtil.getRequestEncryptedKeyId methods:
>>
>>
>> http://svn.apache.org/viewvc/axis/axis2/java/rampart/branches/1_6/modules/rampart-core/src/main/java/org/apache/rampart/builder/AsymmetricBindingBuilder.java?view=markup#l868
>>
>> http://svn.apache.org/viewvc/axis/axis2/java/rampart/branches/1_6/modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java?view=markup#l1442
>>
>> Apparently, it now picks up the result of the ReferenceListProcessor
>> since it has an "id" tag, but since it has empty value, the
>> "AssymetricBindingBuilder.encryptedKeyId" field is also left out empty and
>> this leads to missing token in response...
>> Commenting out the line in the ReferenceListProcessor that adds the "id"
>> tag fixes the issue - Rampart then properly finds the result of the
>> DerivedKeyTokenProcessor and not the one of the ReferenceListProcessor.
>>
>> Now the question is whether this has to be fixed in Rampart or in WSS4J?
>>
>> Regards,
>> Detelin
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 8, 2014 at 6:39 PM, Colm O hEigeartaigh <[email protected]>
>> wrote:
>>
>>> 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, <[email protected]> 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 <
>>>> [email protected]> 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, <[email protected]> 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: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Colm O hEigeartaigh
>>>>>
>>>>> Talend Community Coder
>>>>> http://coders.talend.com
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
