Well the thing is that WSS4J 1.6.16 was just released, and so the next release won't happen for a couple of months probably. So if you want to see a Rampart release before then, you could just submit a patch to check that the Id isn't empty.
Colm. On Wed, Jul 9, 2014 at 1:32 PM, <[email protected]> wrote: > 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 >> > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
