Bug 4136 - At least one of the headers used in dispatch was not secured error
: At least one of the headers used in dispatch was not secured error
Status: RESOLVED FIXED
: Java WS Security
Authentication
: unspecified
: PC Windows XP
: P3 minor
: ---
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2006-01-06 00:33 by
Modified: 2006-01-06 16:57 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-01-06 00:33:43
Tests sometimes fail with:

testGssSignatureAndX509Encryption Error General security error (At least one of 
the headers used in dispatch "{http://schemas.xmlsoap.org/ws/2004/03/addressing}
From" was not secured)

org.globus.wsrf.impl.security.authentication.wssec.WSSecurityException: General 
security error (At least one of the headers used in 
dispatch "{http://schemas.xmlsoap.org/ws/2004/03/addressing}From" was not 
secured) at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.enforceSecur
eDispatchHeaders(WSSecurityEngine.java:172) at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.handleSignat
ureElement(WSSecurityEngine.java:120) at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.processSecur
ityHeader(WSSecurityEngine.java:494) at 
org.globus.wsrf.impl.security.authentication.wssec.WSSecurityEngine.processSecur
ityHeader(WSSecurityEngine.java:460) at 
org.globus.wsrf.impl.security.authentication.TestWSSecurity.verify
(TestWSSecurity.java:456) at 
org.globus.wsrf.impl.security.authentication.TestWSSecurity.testGssSignatureAndX
509Encryption(TestWSSecurity.java:303) at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25) at org.globus.wsrf.test.GridTestSuite.run
(GridTestSuite.java:94)
------- Comment #1 From 2006-01-06 13:53:15 -------
I believe this is caused by having two headers with the same wsu:Id value. For 
example:

<wsa:MessageID SOAP-ENV:mustUnderstand="0" wsu:Id="id-145910" xmlns="" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
utility-1.0.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">uuid:6b4d3d80-2f7a-11d9-
a445-9feae912fa6b</wsa:MessageID>

<wsa:To SOAP-ENV:mustUnderstand="0" wsu:Id="id-145910" xmlns="" xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
utility-1.0.xsd" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">http://140.221.57.28:8080/wsrf/services/SecureCounterService</wsa:To>
------- Comment #2 From 2006-01-06 16:57:29 -------
I think this was caused by a sample soap message in the test code that had 
hardcoded wsu:Id value for one ws-a header. The wsu:Id values for other ws-a 
headers where automatically generated, and sometimes one of the generated 
wsu:Id values would match the hardcoded one causing the error (and the test to 
fail).
I changed the hardcoded value so that it would not conflict anymore with the 
generated ones.