You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by de...@gmail.com on 2014/07/08 13:55:09 UTC
Apache Rampart test failure with wss4j 1.6.5 and later
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
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by de...@gmail.com.
Hi again,
I opened a request in Rampart JIRA to upgrade to wss4j 1.6.16:
RAMPART-415 <https://issues.apache.org/jira/browse/RAMPART-415>. I provided
the patch there, also mentioned about another issue which I discovered
after applying the workaround for the empty Ids.
Regards,
Detelin
On Fri, Jul 11, 2014 at 2:21 AM, <de...@gmail.com> wrote:
> Hi Martin,
> What about this one - it would log empty ids with debug level:
>
> Index:
> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
> ===================================================================
> ---
> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
> (revision 1609336)
> +++
> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
> (working copy)
> @@ -1472,7 +1472,12 @@
>
> String encrKeyId = (String)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
> if (actInt == WSConstants.ENCR &&
> encrKeyId != null) {
> - return encrKeyId;
> + if (encrKeyId.length() > 0) {
> + return encrKeyId;
> + }
> + else if (log.isDebugEnabled()) {
> + log.debug("Found encryption security processing
> result with empty id, skipping it: " + wsSecEngineResult);
> + }
> }
> }
> }
>
> Regards,
> Detelin
>
>
> On Thu, Jul 10, 2014 at 2:30 AM, Martin Gainty <mg...@hotmail.com>
> wrote:
>
>>
>> ------------------------------
>> Date: Wed, 9 Jul 2014 22:48:36 +0300
>>
>> Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
>> From: detelinyordanov@gmail.com
>> To: mgainty@hotmail.com
>> CC: dev@ws.apache.org
>>
>> Hi Martin,
>> I think that the code you are referring to is in
>> SymmetricBindingBuilder and it indeed checks if the Id is empty. However,
>> the one in RampartUtil.getRequestEncryptedKeyId() does not do so. The fix
>> is to add a check for empty Id there as well:
>>
>> Index:
>> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
>> ===================================================================
>> ---
>> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
>> (revision 1608682)
>> +++
>> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
>> (working copy)
>> @@ -1471,7 +1471,7 @@
>> Integer actInt = (Integer)
>> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
>> String encrKeyId = (String)
>> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
>> if (actInt == WSConstants.ENCR &&
>> - encrKeyId != null) {
>> + encrKeyId != null && encrKeyId.length() > 0) {
>> return encrKeyId;
>> }
>> }
>>
>> MG>good that you are not using a null Id ..BETTER if you tell the op they
>> have a NULL ID
>> MG>wsu spec is here
>> MG>
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>>
>> This fix would be needed if/when Rampart upgrades to wss4j version higher
>> than 1.6.4. Once wss4j 1.6.17 is released, the fix will no longer be
>> needed, but it still does not hurt to have it there. Would you like me to
>> open a jira issue about this in Rampart? I was planning to file a request
>> for wss4j upgrade in Rampart and I could mention this issue there and
>> attach the above patch.
>> MG>good idea *if* you log the error otherwise the next guy that
>> implements Rampart will run into the same problem
>>
>> Regards,
>> Detelin
>> MG>Regards
>> MG>Martin
>>
>>
>> On Wed, Jul 9, 2014 at 5:05 PM, Martin Gainty <mg...@hotmail.com>
>> wrote:
>>
>>
>>
>> ------------------------------
>> Date: Wed, 9 Jul 2014 14:23:47 +0100
>> Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
>> From: coheigea@apache.org
>> To: detelinyordanov@gmail.com
>> CC: dev@ws.apache.org
>>
>>
>> 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, <de...@gmail.com> 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
>>
>> MG>the rampart distro that accompanies Axis2-1.6.2 detected the missing
>> tag 'id'
>>
>> for (WSSecurityEngineResult wsSecEngineResult :
>> wsSecEngineResults) {
>> Integer actInt = (Integer)
>> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
>> if (actInt == WSConstants.ENCR) {
>> if
>> (wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID) != null &&
>> ((String)
>> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID)).length() != 0) {
>> try {
>> String encryptedKeyID = (String)
>> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
>>
>> Date created = new Date();
>> Date expires = new Date();
>> expires.setTime(System.currentTimeMillis() +
>> 300000);
>> EncryptedKeyToken tempTok = new
>> EncryptedKeyToken(encryptedKeyID, created, expires);
>> tempTok.setSecret((byte[])
>> wsSecEngineResult.get(WSSecurityEngineResult.TAG_SECRET));
>> tempTok.setSHA1(getSHA1((byte[])
>> wsSecEngineResult.
>>
>> get(WSSecurityEngineResult.TAG_ENCRYPTED_EPHEMERAL_KEY)));
>> rmd.getTokenStorage().add(tempTok);
>>
>> return encryptedKeyID;
>>
>> } catch (TrustException e) {
>> throw new
>> RampartException("errorInAddingTokenIntoStore");
>> }
>> MG>i would add a else condition to toss a message to the op
>> else
>> {
>> throw new
>> RampartException("security_engine_result_missing_id");
>> }
>> MG>end else
>> MG>errors.properties would contain new entry:
>> security_engine_result_missing_id=Rampart
>> Security Engine Result is missing 'id' token element
>> MG>if you make the suggestion for correction I will follow thru and make
>> sure it gets implemented
>> MG>https://issues.apache.org/jira/browse
>> MG>Thanks Detelin,
>> MG>Martin
>>
>>
>> On Wed, Jul 9, 2014 at 12:45 PM, Colm O hEigeartaigh <coheigea@apache.org
>> > 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, <de...@gmail.com> 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 <co...@apache.org>
>> 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, <de...@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 <co...@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, <de...@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
>>
>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>>
>>
>
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by de...@gmail.com.
Hi Martin,
What about this one - it would log empty ids with debug level:
Index:
modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
===================================================================
---
modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
(revision 1609336)
+++
modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
(working copy)
@@ -1472,7 +1472,12 @@
String encrKeyId = (String)
wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
if (actInt == WSConstants.ENCR &&
encrKeyId != null) {
- return encrKeyId;
+ if (encrKeyId.length() > 0) {
+ return encrKeyId;
+ }
+ else if (log.isDebugEnabled()) {
+ log.debug("Found encryption security processing
result with empty id, skipping it: " + wsSecEngineResult);
+ }
}
}
}
Regards,
Detelin
On Thu, Jul 10, 2014 at 2:30 AM, Martin Gainty <mg...@hotmail.com> wrote:
>
> ------------------------------
> Date: Wed, 9 Jul 2014 22:48:36 +0300
>
> Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
> From: detelinyordanov@gmail.com
> To: mgainty@hotmail.com
> CC: dev@ws.apache.org
>
> Hi Martin,
> I think that the code you are referring to is in
> SymmetricBindingBuilder and it indeed checks if the Id is empty. However,
> the one in RampartUtil.getRequestEncryptedKeyId() does not do so. The fix
> is to add a check for empty Id there as well:
>
> Index:
> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
> ===================================================================
> ---
> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
> (revision 1608682)
> +++
> modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
> (working copy)
> @@ -1471,7 +1471,7 @@
> Integer actInt = (Integer)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
> String encrKeyId = (String)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
> if (actInt == WSConstants.ENCR &&
> - encrKeyId != null) {
> + encrKeyId != null && encrKeyId.length() > 0) {
> return encrKeyId;
> }
> }
>
> MG>good that you are not using a null Id ..BETTER if you tell the op they
> have a NULL ID
> MG>wsu spec is here
> MG>
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>
> This fix would be needed if/when Rampart upgrades to wss4j version higher
> than 1.6.4. Once wss4j 1.6.17 is released, the fix will no longer be
> needed, but it still does not hurt to have it there. Would you like me to
> open a jira issue about this in Rampart? I was planning to file a request
> for wss4j upgrade in Rampart and I could mention this issue there and
> attach the above patch.
> MG>good idea *if* you log the error otherwise the next guy that implements
> Rampart will run into the same problem
>
> Regards,
> Detelin
> MG>Regards
> MG>Martin
>
>
> On Wed, Jul 9, 2014 at 5:05 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
>
>
> ------------------------------
> Date: Wed, 9 Jul 2014 14:23:47 +0100
> Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
> From: coheigea@apache.org
> To: detelinyordanov@gmail.com
> CC: dev@ws.apache.org
>
>
> 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, <de...@gmail.com> 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
>
> MG>the rampart distro that accompanies Axis2-1.6.2 detected the missing
> tag 'id'
>
> for (WSSecurityEngineResult wsSecEngineResult :
> wsSecEngineResults) {
> Integer actInt = (Integer)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
> if (actInt == WSConstants.ENCR) {
> if
> (wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID) != null &&
> ((String)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID)).length() != 0) {
> try {
> String encryptedKeyID = (String)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
>
> Date created = new Date();
> Date expires = new Date();
> expires.setTime(System.currentTimeMillis() +
> 300000);
> EncryptedKeyToken tempTok = new
> EncryptedKeyToken(encryptedKeyID, created, expires);
> tempTok.setSecret((byte[])
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_SECRET));
> tempTok.setSHA1(getSHA1((byte[])
> wsSecEngineResult.
>
> get(WSSecurityEngineResult.TAG_ENCRYPTED_EPHEMERAL_KEY)));
> rmd.getTokenStorage().add(tempTok);
>
> return encryptedKeyID;
>
> } catch (TrustException e) {
> throw new
> RampartException("errorInAddingTokenIntoStore");
> }
> MG>i would add a else condition to toss a message to the op
> else
> {
> throw new
> RampartException("security_engine_result_missing_id");
> }
> MG>end else
> MG>errors.properties would contain new entry:
> security_engine_result_missing_id=Rampart Security
> Engine Result is missing 'id' token element
> MG>if you make the suggestion for correction I will follow thru and make
> sure it gets implemented
> MG>https://issues.apache.org/jira/browse
> MG>Thanks Detelin,
> MG>Martin
>
>
> On Wed, Jul 9, 2014 at 12:45 PM, Colm O hEigeartaigh <co...@apache.org>
> 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, <de...@gmail.com> 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 <co...@apache.org>
> 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, <de...@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 <co...@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, <de...@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
>
>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
RE: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by Martin Gainty <mg...@hotmail.com>.
Date: Wed, 9 Jul 2014 22:48:36 +0300
Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
From: detelinyordanov@gmail.com
To: mgainty@hotmail.com
CC: dev@ws.apache.org
Hi Martin,
I think that the code you are referring to is in SymmetricBindingBuilder and it indeed checks if the Id is empty. However, the one in RampartUtil.getRequestEncryptedKeyId() does not do so. The fix is to add a check for empty Id there as well:
Index: modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
===================================================================
--- modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java (revision 1608682)
+++ modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java (working copy)
@@ -1471,7 +1471,7 @@
Integer actInt = (Integer) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
String encrKeyId = (String) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
if (actInt == WSConstants.ENCR &&
- encrKeyId != null) {
+ encrKeyId != null && encrKeyId.length() > 0) {
return encrKeyId;
}
}
MG>good that you are not using a null Id ..BETTER if you tell the op they have a NULL ID
MG>wsu spec is here
MG>http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
This fix would be needed if/when Rampart upgrades to wss4j version higher than 1.6.4. Once wss4j 1.6.17 is released, the fix will no longer be needed, but it still does not hurt to have it there. Would you like me to open a jira issue about this in Rampart? I was planning to file a request for wss4j upgrade in Rampart and I could mention this issue there and attach the above patch.
MG>good idea *if* you log the error otherwise the next guy that implements Rampart will run into the same problem
Regards,
Detelin
MG>Regards
MG>Martin
On Wed, Jul 9, 2014 at 5:05 PM, Martin Gainty <mg...@hotmail.com> wrote:
Date: Wed, 9 Jul 2014 14:23:47 +0100
Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
From: coheigea@apache.org
To: detelinyordanov@gmail.com
CC: dev@ws.apache.org
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, <de...@gmail.com> 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
MG>the rampart distro that accompanies Axis2-1.6.2 detected the missing tag 'id'
for (WSSecurityEngineResult wsSecEngineResult : wsSecEngineResults) {
Integer actInt = (Integer) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
if (actInt == WSConstants.ENCR) {
if (wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID) != null &&
((String) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID)).length() != 0) {
try {
String encryptedKeyID = (String) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
Date created = new Date();
Date expires = new Date();
expires.setTime(System.currentTimeMillis() + 300000);
EncryptedKeyToken tempTok = new EncryptedKeyToken(encryptedKeyID, created, expires);
tempTok.setSecret((byte[]) wsSecEngineResult.get(WSSecurityEngineResult.TAG_SECRET));
tempTok.setSHA1(getSHA1((byte[]) wsSecEngineResult.
get(WSSecurityEngineResult.TAG_ENCRYPTED_EPHEMERAL_KEY)));
rmd.getTokenStorage().add(tempTok);
return encryptedKeyID;
} catch (TrustException e) {
throw new RampartException("errorInAddingTokenIntoStore");
}
MG>i would add a else condition to toss a message to the op
else
{
throw new RampartException("security_engine_result_missing_id");
}
MG>end else
MG>errors.properties would contain new entry:
security_engine_result_missing_id=Rampart Security Engine Result is missing 'id' token element
MG>if you make the suggestion for correction I will follow thru and make sure it gets implemented
MG>https://issues.apache.org/jira/browse
MG>Thanks Detelin,
MG>Martin
On Wed, Jul 9, 2014 at 12:45 PM, Colm O hEigeartaigh <co...@apache.org> 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, <de...@gmail.com> 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 <co...@apache.org> 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, <de...@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 <co...@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, <de...@gmail.com> wrote:
Hi everyone,
Our team worked on new functionality that is to be released with upcoming wss4j 1.6.16 (WSS-500 & 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
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by de...@gmail.com.
Hi Martin,
I think that the code you are referring to is in SymmetricBindingBuilder
and it indeed checks if the Id is empty. However, the one in
RampartUtil.getRequestEncryptedKeyId() does not do so. The fix is to add a
check for empty Id there as well:
Index:
modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
===================================================================
---
modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
(revision 1608682)
+++
modules/rampart-core/src/main/java/org/apache/rampart/util/RampartUtil.java
(working copy)
@@ -1471,7 +1471,7 @@
Integer actInt = (Integer)
wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
String encrKeyId = (String)
wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
if (actInt == WSConstants.ENCR &&
- encrKeyId != null) {
+ encrKeyId != null && encrKeyId.length() > 0) {
return encrKeyId;
}
}
This fix would be needed if/when Rampart upgrades to wss4j version higher
than 1.6.4. Once wss4j 1.6.17 is released, the fix will no longer be
needed, but it still does not hurt to have it there. Would you like me to
open a jira issue about this in Rampart? I was planning to file a request
for wss4j upgrade in Rampart and I could mention this issue there and
attach the above patch.
Regards,
Detelin
On Wed, Jul 9, 2014 at 5:05 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
>
> ------------------------------
> Date: Wed, 9 Jul 2014 14:23:47 +0100
> Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
> From: coheigea@apache.org
> To: detelinyordanov@gmail.com
> CC: dev@ws.apache.org
>
>
> 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, <de...@gmail.com> 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
>
> MG>the rampart distro that accompanies Axis2-1.6.2 detected the missing
> tag 'id'
>
> for (WSSecurityEngineResult wsSecEngineResult :
> wsSecEngineResults) {
> Integer actInt = (Integer)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
> if (actInt == WSConstants.ENCR) {
> if
> (wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID) != null &&
> ((String)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID)).length() != 0) {
> try {
> String encryptedKeyID = (String)
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
>
> Date created = new Date();
> Date expires = new Date();
> expires.setTime(System.currentTimeMillis() +
> 300000);
> EncryptedKeyToken tempTok = new
> EncryptedKeyToken(encryptedKeyID, created, expires);
> tempTok.setSecret((byte[])
> wsSecEngineResult.get(WSSecurityEngineResult.TAG_SECRET));
> tempTok.setSHA1(getSHA1((byte[])
> wsSecEngineResult.
>
> get(WSSecurityEngineResult.TAG_ENCRYPTED_EPHEMERAL_KEY)));
> rmd.getTokenStorage().add(tempTok);
>
> return encryptedKeyID;
>
> } catch (TrustException e) {
> throw new
> RampartException("errorInAddingTokenIntoStore");
> }
> MG>i would add a else condition to toss a message to the op
> else
> {
> throw new
> RampartException("security_engine_result_missing_id");
> }
> MG>end else
> MG>errors.properties would contain new entry:
> security_engine_result_missing_id=Rampart Security
> Engine Result is missing 'id' token element
> MG>if you make the suggestion for correction I will follow thru and make
> sure it gets implemented
> MG>https://issues.apache.org/jira/browse
> MG>Thanks Detelin,
> MG>Martin
>
>
> On Wed, Jul 9, 2014 at 12:45 PM, Colm O hEigeartaigh <co...@apache.org>
> 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, <de...@gmail.com> 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 <co...@apache.org>
> 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, <de...@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 <co...@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, <de...@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
>
>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
RE: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by Martin Gainty <mg...@hotmail.com>.
Date: Wed, 9 Jul 2014 14:23:47 +0100
Subject: Re: Apache Rampart test failure with wss4j 1.6.5 and later
From: coheigea@apache.org
To: detelinyordanov@gmail.com
CC: dev@ws.apache.org
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, <de...@gmail.com> 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
MG>the rampart distro that accompanies Axis2-1.6.2 detected the missing tag 'id'
for (WSSecurityEngineResult wsSecEngineResult : wsSecEngineResults) {
Integer actInt = (Integer) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ACTION);
if (actInt == WSConstants.ENCR) {
if (wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID) != null &&
((String) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID)).length() != 0) {
try {
String encryptedKeyID = (String) wsSecEngineResult.get(WSSecurityEngineResult.TAG_ID);
Date created = new Date();
Date expires = new Date();
expires.setTime(System.currentTimeMillis() + 300000);
EncryptedKeyToken tempTok = new EncryptedKeyToken(encryptedKeyID, created, expires);
tempTok.setSecret((byte[]) wsSecEngineResult.get(WSSecurityEngineResult.TAG_SECRET));
tempTok.setSHA1(getSHA1((byte[]) wsSecEngineResult.
get(WSSecurityEngineResult.TAG_ENCRYPTED_EPHEMERAL_KEY)));
rmd.getTokenStorage().add(tempTok);
return encryptedKeyID;
} catch (TrustException e) {
throw new RampartException("errorInAddingTokenIntoStore");
}
MG>i would add a else condition to toss a message to the op
else
{
throw new RampartException("security_engine_result_missing_id");
}
MG>end else
MG>errors.properties would contain new entry:
security_engine_result_missing_id=Rampart Security Engine Result is missing 'id' token element
MG>if you make the suggestion for correction I will follow thru and make sure it gets implemented
MG>https://issues.apache.org/jira/browse
MG>Thanks Detelin,
MG>Martin
On Wed, Jul 9, 2014 at 12:45 PM, Colm O hEigeartaigh <co...@apache.org> 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, <de...@gmail.com> 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 <co...@apache.org> 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, <de...@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 <co...@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, <de...@gmail.com> wrote:
Hi everyone,
Our team worked on new functionality that is to be released with upcoming wss4j 1.6.16 (WSS-500 & 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
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by Colm O hEigeartaigh <co...@apache.org>.
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, <de...@gmail.com> 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 <co...@apache.org>
> 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, <de...@gmail.com> 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 <coheigea@apache.org
>>> > 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, <de...@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, <de...@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
>>>>
>>>
>>>
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
>>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by de...@gmail.com.
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 <co...@apache.org>
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, <de...@gmail.com> 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 <co...@apache.org>
>> 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, <de...@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, <de...@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
>>>
>>
>>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by Colm O hEigeartaigh <co...@apache.org>.
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, <de...@gmail.com> 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 <co...@apache.org>
> 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, <de...@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, <de...@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
>>
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by de...@gmail.com.
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 <co...@apache.org>
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, <de...@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 <co...@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, <de...@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
>
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by Colm O hEigeartaigh <co...@apache.org>.
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, <de...@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 <co...@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, <de...@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
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by de...@gmail.com.
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 <co...@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, <de...@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
>
Re: Apache Rampart test failure with wss4j 1.6.5 and later
Posted by Colm O hEigeartaigh <co...@apache.org>.
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, <de...@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