This has been fixed in CXF-4414: https://issues.apache.org/jira/browse/CXF-4414
Colm. On Mon, Jul 9, 2012 at 7:51 PM, [email protected] <[email protected]>wrote: > Hello, > > I am currently attempting to use the WS-Security and WS-SecurityPolicy on a > web service. I am running into an issue where the CXF Policy Based > Interceptor (added to the chain because of the existence of the endorsing > supporting tokens policy on my wsdl) is not able to verify the signature of > the endorsing supporting token. I am using TLS so the endorsing supporting > token is a signature of the timestamp element. > > The error I am seeing is: > { > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EndorsingSupportingTokens > : > The received token does not match the endorsing supporting token > requirement > > I have attached a number of files to best describe the phenomenon that I am > seeing: > http://cxf.547215.n5.nabble.com/file/n5710799/NhinXDR20.wsdlNhinXDR20.wsdl > - This is my wsdl with the endorsing supporting tokens policy. > http://cxf.547215.n5.nabble.com/file/n5710799/cxf-servlet.xml > cxf-servlet.xml - This is the definition of my endpoint, I am using the > default CXF policy based interceptor, so no In Interceptor is configured. > http://cxf.547215.n5.nabble.com/file/n5710799/Message.log Message.log - > This is an example of the message received by my endpoint which causes the > exception I am seeing. > http://cxf.547215.n5.nabble.com/file/n5710799/Exception.log Exception.log > - > This is the exception I am seeing. > ({ > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EndorsingSupportingTokens > : > The received token does not match the endorsing supporting token > requirement) > > http://cxf.547215.n5.nabble.com/file/n5710799/AbstractSupportingTokenPolicyValidator.java > AbstractSupportingTokenPolicyValidator.java - For reference. > > While debugging the source (specifically the > AbstractSupportingTokenPolicyValidator.java) I find that the two variables > instansiated on lines 465 and 467 are set to null. > > X509Certificate cert = > > > (X509Certificate)signatureResult.get(WSSecurityEngineResult.TAG_X509_CERTIFICATE); > byte[] secret = > (byte[])signatureResult.get(WSSecurityEngineResult.TAG_SECRET); > > Without a cert or secret to compare against the subject cert or secret, I > can see how the validation would fail. My question is why does the WS > Security Engine not have these results? > > In addition the SAMLKeyInfo on line 485 returns null to both the > .getCerts() > and .getSecret() methods. I suspect this is caused by the KeyInfo in the > message only containing modulus and exponent, however my understanding of > SAML is that it is correct to only provide the public key mod/exp. Any > thoughts? > > Thank you for your time. > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Policy-Based-interceptor-verification-of-Endorsing-Supporting-Tokens-tp5710799.html > Sent from the cxf-user mailing list archive at Nabble.com. > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
