You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by andreas_triebel <an...@adesso.ch> on 2012/11/15 10:25:51 UTC
Signature Interop Issue: Weblogic -> Apache CXF
An iterop scenario with Weblogic as service consumer and Apache CXF (on
JBoss) as service provider fails with a "Referenced security token could not
be retrieved" error.
The referenced security token (SAML assertion) is in place (Reference
"#_0x1f0b85b073c1b3ef9ff63f003b319270"), but CXF cannot resolve it.
Stacktrace:
09:00:25,035 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
Interceptor for SAML2TestService#doit has thrown exception, unwinding now:
org.apache.cxf.binding.soap.SoapFault: The signature or decryption was
invalid
at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.createSoapFault(WSS4JInInterceptor.java:804)
[jbossweb-7.0.13.Final.jar:]
...
Caused by: org.apache.ws.security.WSSecurityException: The signature or
decryption was invalid
at
org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:407)
[wss4j.jar:1.6.7]
at
org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:197)
[wss4j.jar:1.6.7]
at
org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)
[wss4j.jar:1.6.7]
at
org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:289)
... 26 more
Caused by: javax.xml.crypto.dsig.XMLSignatureException:
javax.xml.crypto.dsig.TransformException:
org.apache.ws.security.WSSecurityException: Referenced security token could
not be retrieved (Reference "#_0x1f0b85b073c1b3ef9ff63f003b319270")
at
org.apache.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:543)
[xmlsec.jar:1.5.2]
at
org.apache.jcp.xml.dsig.internal.dom.DOMReference.validate(DOMReference.java:384)
[xmlsec.jar:1.5.2]
at
org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.validate(DOMXMLSignature.java:267)
[xmlsec.jar:1.5.2]
at
org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:380)
[wss4j.jar:1.6.7]
... 29 more
Caused by: javax.xml.crypto.dsig.TransformException:
org.apache.ws.security.WSSecurityException: Referenced security token could
not be retrieved (Reference "#_0x1f0b85b073c1b3ef9ff63f003b319270")
at
org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:274)
[wss4j.jar:1.6.7]
at
org.apache.ws.security.transform.STRTransform.transform(STRTransform.java:127)
[wss4j.jar:1.6.7]
at
org.apache.jcp.xml.dsig.internal.dom.DOMTransform.transform(DOMTransform.java:166)
[xmlsec.jar:1.5.2]
at
org.apache.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:458)
[xmlsec.jar:1.5.2]
... 32 more
Caused by: org.apache.ws.security.WSSecurityException: Referenced security
token could not be retrieved (Reference
"#_0x1f0b85b073c1b3ef9ff63f003b319270")
at
org.apache.ws.security.message.token.SecurityTokenReference.getTokenElement(SecurityTokenReference.java:235)
[wss4j.jar:1.6.7]
at
org.apache.ws.security.transform.STRTransformUtil.dereferenceSTR(STRTransformUtil.java:69)
[wss4j.jar:1.6.7]
at
org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:200)
[wss4j.jar:1.6.7]
... 35 more
SOAP message:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
...
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
S:mustUnderstand="1">
...
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<dsig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<dsig:Reference URI="#str_rF7CzO4LdKFt5zs6">
<dsig:Transforms>
<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</wsse:TransformationParameters>
</dsig:Transform>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
/>
<dsig:DigestValue>iRkzoWPRp+m7x3v9JqX3Q/HdqYU=</dsig:DigestValue>
</dsig:Reference>
...
</dsig:SignedInfo>
<dsig:SignatureValue>...</dsig:SignatureValue>
<dsig:KeyInfo>...</dsig:KeyInfo>
</dsig:Signature>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="_0x1f0b85b073c1b3ef9ff63f003b319270"
IssueInstant="2012-11-15T08:00:24.879Z"
Version="2.0">
...
</saml:Assertion>
<wsse:SecurityTokenReference
TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
wsu:Id="str_rF7CzO4LdKFt5zs6">
<wsse:Reference URI="#_0x1f0b85b073c1b3ef9ff63f003b319270" />
</wsse:SecurityTokenReference>
<wsu:Timestamp>
...
</wsu:Timestamp>
</wsse:Security>
</S:Header>
<S:Body>
...
</S:Body>
</S:Envelope>
What I see is a difference between Weblogic and CXF generated
SecurityTokenReference referencing the SAML assertion.
Is this the issue and how could it be resolved? Any suggestions appreciated.
Weblogic:
<wsse:SecurityTokenReference
TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
wsu:Id="str_rF7CzO4LdKFt5zs6">
<wsse:Reference URI="#_0x1f0b85b073c1b3ef9ff63f003b319270" />
</wsse:SecurityTokenReference>
CXF:
<wsse:SecurityTokenReference
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
wsu:Id="STR-C4F98A4E3E98FE682A135290662529414">
<wsse:KeyIdentifier
ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID">_C4F98A4E3E98FE682A135290662529213</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
--
View this message in context: http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by Colm O hEigeartaigh <co...@apache.org>.
My interpretation of the "token used to generate that signature" is the
actual token itself. The SecurityTokenReference inside the KeyInfo is a
reference to the token. Therefore IMO the WebLogic requirement is incorrect
- however, others may have different opinions on it.
Colm.
On Fri, Nov 23, 2012 at 12:33 PM, andreas_triebel <andreas.triebel@adesso.ch
> wrote:
> This works! Thank you!
>
> Removing the ProtectTokens assertion stops Weblogic from signing resp.
> validating the STR inside the KeyInfo.
>
> I was curious and had a look at the WS-SecurityPolicy 1.2 spec and probably
> Weblogic was right to expect the STR signed?
> /
> 6.5 [Token Protection] Property
> This boolean property specifies whether signatures must cover the token
> used
> to generate that signature. If the value is 'true', then each token used to
> generate a signature MUST be covered by that signature. If the value is
> 'false', then the token MUST NOT be covered by the signature. Note that in
> cases where derived keys are used the 'main' token, and NOT the derived key
> token, is covered by the signature. It is recommended that assertions that
> define values for this property apply to [Endpoint Policy Subject]. The
> default value for this property is 'false'./
>
> -Andreas
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5719030.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by andreas_triebel <an...@adesso.ch>.
This works! Thank you!
Removing the ProtectTokens assertion stops Weblogic from signing resp.
validating the STR inside the KeyInfo.
I was curious and had a look at the WS-SecurityPolicy 1.2 spec and probably
Weblogic was right to expect the STR signed?
/
6.5 [Token Protection] Property
This boolean property specifies whether signatures must cover the token used
to generate that signature. If the value is 'true', then each token used to
generate a signature MUST be covered by that signature. If the value is
'false', then the token MUST NOT be covered by the signature. Note that in
cases where derived keys are used the 'main' token, and NOT the derived key
token, is covered by the signature. It is recommended that assertions that
define values for this property apply to [Endpoint Policy Subject]. The
default value for this property is 'false'./
-Andreas
--
View this message in context: http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5719030.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by Colm O hEigeartaigh <co...@apache.org>.
Try removing the "<ns1:ProtectTokens />" assertion and see if it works. It
is possible that WebLogic is interpreting this policy to mean that the STR
in the KeyInfo must be signed.
Colm.
On Fri, Nov 23, 2012 at 11:50 AM, andreas_triebel <andreas.triebel@adesso.ch
> wrote:
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by andreas_triebel <an...@adesso.ch>.
Here's the policy, it's the SAML2 SV asym. policy, which ships with Weblogic.
I customized it by removing the OnlySignEntireHeadersAndBody assertion and
adding the SignedParts assertion. (I also tried with the
OnlySignEntireHeadersAndBody assertion with the same result.)
<wsp1_2:Policy
wssutil:Id="Wssp1.2-2007-Saml2.0-SenderVouches-Wss1.1-Asymmetric.xml">
<ns1:AsymmetricBinding
xmlns:ns1="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp1_2:Policy>
<ns1:InitiatorToken>
<wsp1_2:Policy>
<ns1:X509Token
ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp1_2:Policy>
<ns1:RequireThumbprintReference />
<ns1:WssX509V3Token11 />
</wsp1_2:Policy>
</ns1:X509Token>
</wsp1_2:Policy>
</ns1:InitiatorToken>
<ns1:RecipientToken>
<wsp1_2:Policy>
<ns1:X509Token
ns1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">
<wsp1_2:Policy>
<ns1:RequireThumbprintReference />
<ns1:WssX509V3Token11 />
</wsp1_2:Policy>
</ns1:X509Token>
</wsp1_2:Policy>
</ns1:RecipientToken>
<ns1:AlgorithmSuite>
<wsp1_2:Policy>
<ns1:Basic256 />
</wsp1_2:Policy>
</ns1:AlgorithmSuite>
<ns1:Layout>
<wsp1_2:Policy>
<ns1:Lax />
</wsp1_2:Policy>
</ns1:Layout>
<ns1:IncludeTimestamp />
<ns1:ProtectTokens />
</wsp1_2:Policy>
</ns1:AsymmetricBinding>
<ns2:SignedSupportingTokens
xmlns:ns2="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp1_2:Policy>
<ns2:SamlToken
ns2:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp1_2:Policy>
<ns2:WssSamlV20Token11 />
</wsp1_2:Policy>
</ns2:SamlToken>
</wsp1_2:Policy>
</ns2:SignedSupportingTokens>
<ns3:Wss11
xmlns:ns3="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<wsp1_2:Policy>
<ns3:MustSupportRefKeyIdentifier />
<ns3:MustSupportRefIssuerSerial />
<ns3:MustSupportRefThumbprint />
<ns3:MustSupportRefEncryptedKey />
<ns3:RequireSignatureConfirmation />
</wsp1_2:Policy>
</ns3:Wss11>
<sp:SignedParts
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body/>
</sp:SignedParts>
</wsp1_2:Policy>
-Andreas
--
View this message in context: http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5719016.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by Colm O hEigeartaigh <co...@apache.org>.
I don't think it's possible to sign the STR inside the KeyInfo. I don't
recall ever seeing a signature signing its own KeyInfo content before.
Could you attach the security policy that is generating the request?
Colm.
On Fri, Nov 23, 2012 at 9:17 AM, andreas_triebel
<an...@adesso.ch>wrote:
> Hi Andrei
>
> Thanks for the infos about the signing behavior in CXF, this helps me to
> understand the difference between Weblogic and CXF.
>
> Still I don't get the STR inside the KeyInfo signed in the CXF response.
>
> I'm not very familiar with the SignedParts/SignedElements assertions, could
> someone please provide the right SignedParts or SignedElements assertion to
> sign the STR shown in the previous post? Thanks in advance.
>
> I tried these two:
>
> <sp:SignedParts
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
> <sp:Body/>
> <sp:Header Name="SecurityTokenReference"
> Namespace="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "/>
> </sp:SignedParts>
>
> and
>
> <sp:SignedParts
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
> <sp:Body/>
> </sp:SignedParts>
> <sp:SignedElements
> xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
>
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> ">
>
> <sp:XPath>/soap:Envelope/soap:Header/wsse:Security/ds:Signature/ds:KeyInfo/wsse:SecurityTokenReference</sp:XPath>
> </sp:SignedElements>
>
> -Andreas
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5719000.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Signature Interop Issue: Weblogic -> Apache CXF
Posted by andreas_triebel <an...@adesso.ch>.
Hi Andrei
Thanks for the infos about the signing behavior in CXF, this helps me to
understand the difference between Weblogic and CXF.
Still I don't get the STR inside the KeyInfo signed in the CXF response.
I'm not very familiar with the SignedParts/SignedElements assertions, could
someone please provide the right SignedParts or SignedElements assertion to
sign the STR shown in the previous post? Thanks in advance.
I tried these two:
<sp:SignedParts
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body/>
<sp:Header Name="SecurityTokenReference"
Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>
</sp:SignedParts>
and
<sp:SignedParts
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Body/>
</sp:SignedParts>
<sp:SignedElements
xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<sp:XPath>/soap:Envelope/soap:Header/wsse:Security/ds:Signature/ds:KeyInfo/wsse:SecurityTokenReference</sp:XPath>
</sp:SignedElements>
-Andreas
--
View this message in context: http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5719000.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: Signature Interop Issue: Weblogic -> Apache CXF
Posted by Andrei Shakirin <as...@talend.com>.
Hi,
> /<sp:OnlySignEntireHeadersAndBody />/ seems to be ignored by CXF (in
> request and response)
Just put Colm's answer from thread http://mail-archives.apache.org/mod_mbox/cxf-users/201204.mbox/%3CCAB8XdGASib+fc4BHeFhfxGQj7FJtSw-4AFtQ5OAKh7y8n0qi6A@mail.gmail.com%3E:
"My reading of the spec is that a "OnlySignEntireHeadersAndBody" policy means that *if*
message level signature is used in the request, then it must not be a child element of the
SOAP Body, or a child element of a particular header, excepting the security header. It does
not mandate that signature must be performed, only that if signature is performed it must
conform to that policy. Therefore, a SignedParts or SignedElements policy is needed to specify
what must actually be signed."
So just specify "OnlySignEntireHeadersAndBody" assertion is not enough to sign body and header. It just controls that no child elements are signed.
You need to add <sp:SignedParts>...</SignedParts> assertion with body and top level SOAP headers to be signed, for example:
<sp:SignedParts xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
<sp:Header Name="MetadataBindingContainer" Namespace="urn:int:test:ia:metadatabinding:draft" />
<sp:Body />
</sp:SignedParts>
AFAIK you need explicitly define headers to be signed.
Cheers,
Andrei.
> -----Original Message-----
> From: andreas_triebel [mailto:andreas.triebel@adesso.ch]
> Sent: Donnerstag, 22. November 2012 13:34
> To: users@cxf.apache.org
> Subject: Re: Signature Interop Issue: Weblogic -> Apache CXF
>
> The issue with the Weblogic CertPathSelector could be resolved on Weblogic.
>
> But now it seems that Weblogic insists on having signed everything in the
> security header in the response saying "Error on verifying message against
> security policy Error code:3701"
> A look at the Weblogic source confirms that.
>
> CXF signs the Timestamp, SignatureConfirmation and Body in the response,
> but not the STR.
> How do I tell CXF to sign everything in the security header in the response?
>
> /<sp:OnlySignEntireHeadersAndBody />/ seems to be ignored by CXF (in
> request and response)
>
> and
>
> /<sp:SignedParts>...</SignedParts>/ also does not force CXF to sign the STR
> referencing the X509 certificate, at least I did not find the right combination.
>
> CXF response with unsigned STR:
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <wsse:Security..>
> :
> <ds:Signature
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-18">
> :
> <ds:SignedInfo>
> <ds:Reference URI="#TS-
> 16">..</ds:Reference>
> <ds:Reference URI="#SC-
> 17">..</ds:Reference>
> <ds:Reference URI="#Id-
> 12354411">..</ds:Reference>
> </ds:SignedInfo>
>
> <ds:SignatureValue>IbuCvduZIepSG4G8OtdLIeV+MCheIv+eIGhY8FsfDyfKE3
> hk6V9vB2KQmP83diNA0oDw30P3ugn2B6M0Un7R9xmLE70OG0Dpj6my73ML
> e5+48rNeAaVtrTX839VEFvRzvcBCif8mEQOS5JIPlhAXNEBu1+J3Qr3NPItamU0k
> A3c=
> </ds:SignatureValue>
> <ds:KeyInfo Id="KI-
> 120F582AC27EBFB0FE135358458436417">
> *<wsse:SecurityTokenReference
> wsu:Id="STR-
> 120F582AC27EBFB0FE135358458436418">
> <wsse:KeyIdentifier
>
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
> soap-message-security-1.0#Base64Binary"
>
> ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-
> security-
> 1.1#ThumbprintSHA1">R0VTd2CEaTTD3qJ/lAomm31HARQ=</wsse:KeyIdent
> ifier>
> </wsse:SecurityTokenReference>*
> </ds:KeyInfo>
> </ds:Signature>
> </wsse:Security>
> </soap:Header>
> <soap:Body wsu:Id="Id-12354411">
> :
> </soap:Body>
> </soap:Envelope>
>
> -Andreas
>
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Signature-
> Interop-Issue-Weblogic-Apache-CXF-tp5718487p5718960.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by andreas_triebel <an...@adesso.ch>.
The issue with the Weblogic CertPathSelector could be resolved on Weblogic.
But now it seems that Weblogic insists on having signed everything in the
security header in the response saying
"Error on verifying message against security policy Error code:3701"
A look at the Weblogic source confirms that.
CXF signs the Timestamp, SignatureConfirmation and Body in the response, but
not the STR.
How do I tell CXF to sign everything in the security header in the response?
/<sp:OnlySignEntireHeadersAndBody />/ seems to be ignored by CXF (in request
and response)
and
/<sp:SignedParts>...</SignedParts>/ also does not force CXF to sign the STR
referencing the X509 certificate, at least I did not find the right
combination.
CXF response with unsigned STR:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security..>
:
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-18">
:
<ds:SignedInfo>
<ds:Reference URI="#TS-16">..</ds:Reference>
<ds:Reference URI="#SC-17">..</ds:Reference>
<ds:Reference URI="#Id-12354411">..</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>IbuCvduZIepSG4G8OtdLIeV+MCheIv+eIGhY8FsfDyfKE3hk6V9vB2KQmP83diNA0oDw30P3ugn2B6M0Un7R9xmLE70OG0Dpj6my73MLe5+48rNeAaVtrTX839VEFvRzvcBCif8mEQOS5JIPlhAXNEBu1+J3Qr3NPItamU0kA3c=
</ds:SignatureValue>
<ds:KeyInfo Id="KI-120F582AC27EBFB0FE135358458436417">
*<wsse:SecurityTokenReference
wsu:Id="STR-120F582AC27EBFB0FE135358458436418">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">R0VTd2CEaTTD3qJ/lAomm31HARQ=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>*
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body wsu:Id="Id-12354411">
:
</soap:Body>
</soap:Envelope>
-Andreas
--
View this message in context: http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5718960.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Andreas,
Nothing obvious is jumping out at the me. Perhaps change the referencing
mechanism in the security policy from ThumbprintSHA1 to something like
IssuerSerial and see if that works instead?
Colm.
On Mon, Nov 19, 2012 at 8:17 AM, andreas_triebel
<an...@adesso.ch>wrote:
> Hi Colm
>
> Thanks for the patch! I tried the 1.6.8-SNAPSHOT and it works now for the
> request from Weblogic to CXF.
>
> The bad thing is that Weblogic now complains about the response received
> from CXF. Probably this is now an issue on Weblogic and therefore not the
> right place here, but at least I give the information for completeness.
>
> I already tried to resolve this issue on Weblogic by configuring a
> CertificateRegistry as proposed in this blog
>
> http://fusionsecurity.blogspot.ch/2009/08/so-thats-what-weblogic-certificate.html
> with no success.
>
> Error Stacktrace Weblogic:
> ####<Nov 19, 2012 8:39:51 AM CET> <Error> <> <[ACTIVE] ExecuteThread: '0'
> for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
> <35e64a9808ed1790:3007597b:13b179b1226:-8000-0000000000000004>
> <1353310791212> <BEA-000000> <CertPathBuilder does not support building
> cert
> path from class weblogic.security.pk.X509ThumbprintSelector
> java.security.InvalidAlgorithmParameterException: [Security:090596]The
> WebLogicCertPathProvider was passed an unsupported CertPathSelector.
> at
>
> weblogic.security.providers.pk.WebLogicCertPathProviderRuntimeImpl$JDKCertPathBuilder.engineBuild(WebLogicCertPathProviderRuntimeImpl.java:689)
> at
> java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
> at
>
> com.bea.common.security.internal.legacy.service.CertPathBuilderImpl$CertPathBuilderProviderImpl.build(CertPathBuilderImpl.java:67)
> at
>
> com.bea.common.security.internal.service.CertPathBuilderServiceImpl.build(CertPathBuilderServiceImpl.java:86)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
>
> com.bea.common.security.internal.utils.Delegator$ProxyInvocationHandler.invoke(Delegator.java:57)
> at $Proxy59.build(Unknown Source)
> at
>
> weblogic.security.service.WLSCertPathBuilderServiceWrapper.build(WLSCertPathBuilderServiceWrapper.java:62)
> at
> weblogic.security.service.CertPathManager.build(CertPathManager.java:195)
> at
>
> weblogic.security.service.CertPathManager$JDKCertPathBuilder.engineBuild(CertPathManager.java:265)
> at
> java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
> at
> weblogic.xml.crypto.utils.CertUtils.buildCertPath(CertUtils.java:159)
> at
> weblogic.xml.crypto.utils.CertUtils.lookupCertificate(CertUtils.java:124)
> at
> weblogic.xml.crypto.utils.CertUtils.lookupCertificate(CertUtils.java:108)
> at
>
> weblogic.xml.crypto.wss11.internal.bst.BSTHandler.lookupCertificate(BSTHandler.java:79)
> at
>
> weblogic.xml.crypto.wss11.internal.bst.BSTHandler.getTokenByKeyId(BSTHandler.java:59)
> at
>
> weblogic.xml.crypto.wss.BinarySecurityTokenHandler.getSecurityToken(BinarySecurityTokenHandler.java:80)
> at
>
> weblogic.xml.crypto.common.keyinfo.KeyResolver.setupKeyProviderFromContext(KeyResolver.java:344)
> at
>
> weblogic.xml.crypto.common.keyinfo.KeyResolver.getKeyFromSTR(KeyResolver.java:295)
> at
> weblogic.xml.crypto.common.keyinfo.KeyResolver.select(KeyResolver.java:127)
> at
>
> weblogic.xml.crypto.dsig.SignedInfoImpl.getVerifyKey(SignedInfoImpl.java:227)
> at
>
> weblogic.xml.crypto.dsig.SignedInfoImpl.validateSignature(SignedInfoImpl.java:113)
> at
>
> weblogic.xml.crypto.dsig.XMLSignatureImpl.validate(XMLSignatureImpl.java:265)
> at
>
> weblogic.xml.crypto.wss.SecurityImpl.unmarshalAndProcessSignature(SecurityImpl.java:724)
> at
>
> weblogic.xml.crypto.wss.SecurityImpl.unmarshalAndProcessSignature(SecurityImpl.java:689)
> at
>
> weblogic.xml.crypto.wss.SecurityImpl.unmarshalChildren(SecurityImpl.java:544)
> at
>
> weblogic.xml.crypto.wss.SecurityImpl.unmarshalInternal(SecurityImpl.java:450)
> at
> weblogic.xml.crypto.wss.SecurityImpl.unmarshal(SecurityImpl.java:418)
> at
>
> weblogic.xml.crypto.wss11.internal.WSS11Factory.unmarshalAndProcessSecurity(WSS11Factory.java:33)
> at
>
> weblogic.wsee.security.wssp.handlers.WssClientHandler.processInbound(WssClientHandler.java:149)
> at
>
> weblogic.wsee.security.wssp.handlers.WssClientHandler.processResponse(WssClientHandler.java:134)
> at
>
> weblogic.wsee.security.wssp.handlers.WssHandler.handleResponse(WssHandler.java:206)
>
> I don't see much difference between a Weblogic generated response and a CXF
> generated one, besides the fact that in Weblogic the STR inside the KeyInfo
> is signed, in CXF it's not. But this should not be the problem I guess?!
>
> CXF SOAP response:
> <soap:Envelope
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Header>
> <wsse:Security
>
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> soap:mustUnderstand="1">
> <wsu:Timestamp wsu:Id="TS-1">
>
> <wsu:Created>2012-11-16T12:50:55.054Z</wsu:Created>
>
> <wsu:Expires>2012-11-16T12:55:55.054Z</wsu:Expires>
> </wsu:Timestamp>
> <wsse11:SignatureConfirmation
>
> xmlns:wsse11="
> http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>
>
> Value="WuJ58vqiRvVEO72+2YL421WdYt1J6C3skhl8ih7ky16sSIyfOOTPShzqSSq/Va9BQ1uwplnJfX7io8LM4gw0X5LEAzIeoy2dCeiHA4GY5KiO9K0Sh17gJhZoqR5l17oZrfnJUzXvDGUA5eupnl1BqZ1l0c0PJMslnSavwkcmVSA="
> wsu:Id="SC-2" />
> <ds:Signature xmlns:ds="
> http://www.w3.org/2000/09/xmldsig#"
> Id="SIG-3">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod
> Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#">
> <ec:InclusiveNamespaces
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
> PrefixList="soap"
> />
> </ds:CanonicalizationMethod>
> <ds:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
> <ds:Reference URI="#TS-1">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>
> <ec:InclusiveNamespaces
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse
> soap" />
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>
> <ds:DigestValue>OgsxMMNFLQsz/9IsfVQs/oLuc+8=</ds:DigestValue>
> </ds:Reference>
> <ds:Reference URI="#SC-2">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>
> <ec:InclusiveNamespaces
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse
> soap" />
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>
> <ds:DigestValue>oG+UlTKMXY7/IbQpRxvPYySh60Y=</ds:DigestValue>
> </ds:Reference>
> <ds:Reference URI="#Id-3417205">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
>
> <ec:InclusiveNamespaces
>
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="" />
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
>
> <ds:DigestValue>rS4jFUikjRJY+jt6IKSIX7GXNWE=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
>
>
> <ds:SignatureValue>nX8nGcTY7Olu0UBX1S6KbKsGlP8exYu4FdSYCDCPWNm+pUH2PG7B8JJ2yJYFlL919nJUtOnndWYX7s3/eDTTQtR0hPWc6FNs0+yGr7yH6pSWlsbCf+a7n++FG8O+NKe6d2IyvJ4epLvgVVYaoj1RWYcPx31iAvTw6d7S16jZ184=
> </ds:SignatureValue>
> <ds:KeyInfo
> Id="KI-A18E11179961A8826E13530702550772">
> <wsse:SecurityTokenReference
> wsu:Id="STR-A18E11179961A8826E13530702550773">
> <wsse:KeyIdentifier
>
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> "
>
> ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
> ">R0VTd2CEaTTD3qJ/lAomm31HARQ=</wsse:KeyIdentifier>
> </wsse:SecurityTokenReference>
> </ds:KeyInfo>
> </ds:Signature>
> </wsse:Security>
> </soap:Header>
> <soap:Body
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="Id-3417205">
> <ns2:doitResponse xmlns:ns2="http://ws.ssotest/">
> <return>doit() called.</return>
> </ns2:doitResponse>
> </soap:Body>
> </soap:Envelope>
>
> Weblogic SOAP response for comparison:
> <?xml version='1.0' encoding='UTF-8'?>
> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
> <S:Header>
> <wsse:Security
>
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> S:mustUnderstand="1">
> <wsse11:SignatureConfirmation
>
> xmlns:wsse11="
> http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>
>
> Value="BX/qFA56YzPI4Ybtmiqqk2BBqQHDA9FZ+fNwCXC++Tfb8PAQWTwjp8WRVyeCw5f1vMT9ABi8p2bUkdi/Z2T/cQ4D2hf3Y6SbZVu2v08yh8QZFSRubGqKGFqhV0Z6MSjdrj64nu7JMDKWe4OwSUZf58khfx6Kij7j+Eo2Jqq8k4Y="
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="sigconf_Y1dLkZE12R3lo84g" />
> <dsig:Signature xmlns:dsig="
> http://www.w3.org/2000/09/xmldsig#">
> <dsig:SignedInfo>
> <dsig:CanonicalizationMethod
> Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#" />
> <dsig:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
> <dsig:Reference
> URI="#Timestamp_fyeHCdDCF1Q1mEQT">
> <dsig:Transforms>
> <dsig:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
> />
> </dsig:Transforms>
> <dsig:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
> />
>
> <dsig:DigestValue>U6EZCrkoZVK51ldTBm01yjGvTqo=</dsig:DigestValue>
> </dsig:Reference>
> <dsig:Reference
> URI="#Body_dak1e6clIuiK32Q8">
> <dsig:Transforms>
> <dsig:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
> />
> </dsig:Transforms>
> <dsig:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
> />
>
> <dsig:DigestValue>GpX21h7vU1Sv/5fAltIB7AC9JLk=</dsig:DigestValue>
> </dsig:Reference>
> <dsig:Reference
> URI="#sigconf_Y1dLkZE12R3lo84g">
> <dsig:Transforms>
> <dsig:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
> />
> </dsig:Transforms>
> <dsig:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
> />
>
> <dsig:DigestValue>H/1u/9+eXPty0gZry3P6kC9lVjE=</dsig:DigestValue>
> </dsig:Reference>
> <dsig:Reference
> URI="#str_dEoDQOLRAT5qy2ha">
> <dsig:Transforms>
> <dsig:Transform
>
> Algorithm="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform
> ">
>
> <wsse:TransformationParameters>
>
> <dsig:CanonicalizationMethod
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
>
> </wsse:TransformationParameters>
> </dsig:Transform>
> </dsig:Transforms>
> <dsig:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
> />
>
> <dsig:DigestValue>QwS0Bh2Dck6G5rCKyyGwLzCivGM=</dsig:DigestValue>
> </dsig:Reference>
> </dsig:SignedInfo>
>
>
> <dsig:SignatureValue>KsGzFjk9DEF56FfVQt9LnTHu7IWYrMu338Y8ntQWVXkIUp/+aUq2tAHWdG0uRyGwgyptkvyU2sAiHszLcHUXUSjt1MtIzHRNooEPsEzJCeeLDlrwhZ/zRglRMcLveI5rdWZYJmTRKo8zGyuCHesHqUWslWQBrbBW8rlIt0ZSwtg=</dsig:SignatureValue>
> <dsig:KeyInfo>
> <wsse:SecurityTokenReference
>
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
>
> xmlns:wsse11="
> http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
>
> wsse11:TokenType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
> "
>
> wsu:Id="str_dEoDQOLRAT5qy2ha">
> <wsse:KeyIdentifier
>
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> "
>
> ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1
> ">SSp+oSTFJ/0AMjafPrgRAJyDZRg=</wsse:KeyIdentifier>
> </wsse:SecurityTokenReference>
> </dsig:KeyInfo>
> </dsig:Signature>
> <wsu:Timestamp
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="Timestamp_fyeHCdDCF1Q1mEQT">
>
> <wsu:Created>2012-11-16T15:13:20Z</wsu:Created>
>
> <wsu:Expires>2012-11-16T15:14:20Z</wsu:Expires>
> </wsu:Timestamp>
> </wsse:Security>
> </S:Header>
> <S:Body
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="Body_dak1e6clIuiK32Q8">
> <ns0:doitResponse xmlns:ns0="http://ws.ssotest/">
> <return>triebela called web service
> 'SAML2TestService.doit'
> successfully.</return>
> </ns0:doitResponse>
> </S:Body>
> </S:Envelope>
>
> -Andreas
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5718688.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by andreas_triebel <an...@adesso.ch>.
Hi Colm
Thanks for the patch! I tried the 1.6.8-SNAPSHOT and it works now for the
request from Weblogic to CXF.
The bad thing is that Weblogic now complains about the response received
from CXF. Probably this is now an issue on Weblogic and therefore not the
right place here, but at least I give the information for completeness.
I already tried to resolve this issue on Weblogic by configuring a
CertificateRegistry as proposed in this blog
http://fusionsecurity.blogspot.ch/2009/08/so-thats-what-weblogic-certificate.html
with no success.
Error Stacktrace Weblogic:
####<Nov 19, 2012 8:39:51 AM CET> <Error> <> <[ACTIVE] ExecuteThread: '0'
for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <>
<35e64a9808ed1790:3007597b:13b179b1226:-8000-0000000000000004>
<1353310791212> <BEA-000000> <CertPathBuilder does not support building cert
path from class weblogic.security.pk.X509ThumbprintSelector
java.security.InvalidAlgorithmParameterException: [Security:090596]The
WebLogicCertPathProvider was passed an unsupported CertPathSelector.
at
weblogic.security.providers.pk.WebLogicCertPathProviderRuntimeImpl$JDKCertPathBuilder.engineBuild(WebLogicCertPathProviderRuntimeImpl.java:689)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
at
com.bea.common.security.internal.legacy.service.CertPathBuilderImpl$CertPathBuilderProviderImpl.build(CertPathBuilderImpl.java:67)
at
com.bea.common.security.internal.service.CertPathBuilderServiceImpl.build(CertPathBuilderServiceImpl.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.bea.common.security.internal.utils.Delegator$ProxyInvocationHandler.invoke(Delegator.java:57)
at $Proxy59.build(Unknown Source)
at
weblogic.security.service.WLSCertPathBuilderServiceWrapper.build(WLSCertPathBuilderServiceWrapper.java:62)
at
weblogic.security.service.CertPathManager.build(CertPathManager.java:195)
at
weblogic.security.service.CertPathManager$JDKCertPathBuilder.engineBuild(CertPathManager.java:265)
at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
at weblogic.xml.crypto.utils.CertUtils.buildCertPath(CertUtils.java:159)
at
weblogic.xml.crypto.utils.CertUtils.lookupCertificate(CertUtils.java:124)
at
weblogic.xml.crypto.utils.CertUtils.lookupCertificate(CertUtils.java:108)
at
weblogic.xml.crypto.wss11.internal.bst.BSTHandler.lookupCertificate(BSTHandler.java:79)
at
weblogic.xml.crypto.wss11.internal.bst.BSTHandler.getTokenByKeyId(BSTHandler.java:59)
at
weblogic.xml.crypto.wss.BinarySecurityTokenHandler.getSecurityToken(BinarySecurityTokenHandler.java:80)
at
weblogic.xml.crypto.common.keyinfo.KeyResolver.setupKeyProviderFromContext(KeyResolver.java:344)
at
weblogic.xml.crypto.common.keyinfo.KeyResolver.getKeyFromSTR(KeyResolver.java:295)
at
weblogic.xml.crypto.common.keyinfo.KeyResolver.select(KeyResolver.java:127)
at
weblogic.xml.crypto.dsig.SignedInfoImpl.getVerifyKey(SignedInfoImpl.java:227)
at
weblogic.xml.crypto.dsig.SignedInfoImpl.validateSignature(SignedInfoImpl.java:113)
at
weblogic.xml.crypto.dsig.XMLSignatureImpl.validate(XMLSignatureImpl.java:265)
at
weblogic.xml.crypto.wss.SecurityImpl.unmarshalAndProcessSignature(SecurityImpl.java:724)
at
weblogic.xml.crypto.wss.SecurityImpl.unmarshalAndProcessSignature(SecurityImpl.java:689)
at
weblogic.xml.crypto.wss.SecurityImpl.unmarshalChildren(SecurityImpl.java:544)
at
weblogic.xml.crypto.wss.SecurityImpl.unmarshalInternal(SecurityImpl.java:450)
at weblogic.xml.crypto.wss.SecurityImpl.unmarshal(SecurityImpl.java:418)
at
weblogic.xml.crypto.wss11.internal.WSS11Factory.unmarshalAndProcessSecurity(WSS11Factory.java:33)
at
weblogic.wsee.security.wssp.handlers.WssClientHandler.processInbound(WssClientHandler.java:149)
at
weblogic.wsee.security.wssp.handlers.WssClientHandler.processResponse(WssClientHandler.java:134)
at
weblogic.wsee.security.wssp.handlers.WssHandler.handleResponse(WssHandler.java:206)
I don't see much difference between a Weblogic generated response and a CXF
generated one, besides the fact that in Weblogic the STR inside the KeyInfo
is signed, in CXF it's not. But this should not be the problem I guess?!
CXF SOAP response:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
soap:mustUnderstand="1">
<wsu:Timestamp wsu:Id="TS-1">
<wsu:Created>2012-11-16T12:50:55.054Z</wsu:Created>
<wsu:Expires>2012-11-16T12:55:55.054Z</wsu:Expires>
</wsu:Timestamp>
<wsse11:SignatureConfirmation
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
Value="WuJ58vqiRvVEO72+2YL421WdYt1J6C3skhl8ih7ky16sSIyfOOTPShzqSSq/Va9BQ1uwplnJfX7io8LM4gw0X5LEAzIeoy2dCeiHA4GY5KiO9K0Sh17gJhZoqR5l17oZrfnJUzXvDGUA5eupnl1BqZ1l0c0PJMslnSavwkcmVSA="
wsu:Id="SC-2" />
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
Id="SIG-3">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
PrefixList="soap" />
</ds:CanonicalizationMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#TS-1">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse
soap" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>OgsxMMNFLQsz/9IsfVQs/oLuc+8=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#SC-2">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse
soap" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>oG+UlTKMXY7/IbQpRxvPYySh60Y=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#Id-3417205">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="" />
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<ds:DigestValue>rS4jFUikjRJY+jt6IKSIX7GXNWE=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>nX8nGcTY7Olu0UBX1S6KbKsGlP8exYu4FdSYCDCPWNm+pUH2PG7B8JJ2yJYFlL919nJUtOnndWYX7s3/eDTTQtR0hPWc6FNs0+yGr7yH6pSWlsbCf+a7n++FG8O+NKe6d2IyvJ4epLvgVVYaoj1RWYcPx31iAvTw6d7S16jZ184=
</ds:SignatureValue>
<ds:KeyInfo Id="KI-A18E11179961A8826E13530702550772">
<wsse:SecurityTokenReference
wsu:Id="STR-A18E11179961A8826E13530702550773">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">R0VTd2CEaTTD3qJ/lAomm31HARQ=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</soap:Header>
<soap:Body
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Id-3417205">
<ns2:doitResponse xmlns:ns2="http://ws.ssotest/">
<return>doit() called.</return>
</ns2:doitResponse>
</soap:Body>
</soap:Envelope>
Weblogic SOAP response for comparison:
<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
S:mustUnderstand="1">
<wsse11:SignatureConfirmation
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
Value="BX/qFA56YzPI4Ybtmiqqk2BBqQHDA9FZ+fNwCXC++Tfb8PAQWTwjp8WRVyeCw5f1vMT9ABi8p2bUkdi/Z2T/cQ4D2hf3Y6SbZVu2v08yh8QZFSRubGqKGFqhV0Z6MSjdrj64nu7JMDKWe4OwSUZf58khfx6Kij7j+Eo2Jqq8k4Y="
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="sigconf_Y1dLkZE12R3lo84g" />
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<dsig:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<dsig:Reference URI="#Timestamp_fyeHCdDCF1Q1mEQT">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
/>
<dsig:DigestValue>U6EZCrkoZVK51ldTBm01yjGvTqo=</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#Body_dak1e6clIuiK32Q8">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
/>
<dsig:DigestValue>GpX21h7vU1Sv/5fAltIB7AC9JLk=</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#sigconf_Y1dLkZE12R3lo84g">
<dsig:Transforms>
<dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"
/>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
/>
<dsig:DigestValue>H/1u/9+eXPty0gZry3P6kC9lVjE=</dsig:DigestValue>
</dsig:Reference>
<dsig:Reference URI="#str_dEoDQOLRAT5qy2ha">
<dsig:Transforms>
<dsig:Transform
Algorithm="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform">
<wsse:TransformationParameters>
<dsig:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</wsse:TransformationParameters>
</dsig:Transform>
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
/>
<dsig:DigestValue>QwS0Bh2Dck6G5rCKyyGwLzCivGM=</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>KsGzFjk9DEF56FfVQt9LnTHu7IWYrMu338Y8ntQWVXkIUp/+aUq2tAHWdG0uRyGwgyptkvyU2sAiHszLcHUXUSjt1MtIzHRNooEPsEzJCeeLDlrwhZ/zRglRMcLveI5rdWZYJmTRKo8zGyuCHesHqUWslWQBrbBW8rlIt0ZSwtg=</dsig:SignatureValue>
<dsig:KeyInfo>
<wsse:SecurityTokenReference
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsse11="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsse11:TokenType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="str_dEoDQOLRAT5qy2ha">
<wsse:KeyIdentifier
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbprintSHA1">SSp+oSTFJ/0AMjafPrgRAJyDZRg=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
</dsig:KeyInfo>
</dsig:Signature>
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Timestamp_fyeHCdDCF1Q1mEQT">
<wsu:Created>2012-11-16T15:13:20Z</wsu:Created>
<wsu:Expires>2012-11-16T15:14:20Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</S:Header>
<S:Body
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Body_dak1e6clIuiK32Q8">
<ns0:doitResponse xmlns:ns0="http://ws.ssotest/">
<return>triebela called web service 'SAML2TestService.doit'
successfully.</return>
</ns0:doitResponse>
</S:Body>
</S:Envelope>
-Andreas
--
View this message in context: http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487p5718688.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Signature Interop Issue: Weblogic -> Apache CXF
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Andreas,
This will be fixed for WSS4J 1.6.8:
https://issues.apache.org/jira/browse/WSS-411
The problem is really that WSS4J is not catering for a somewhat unusual
request that Weblogic is generating. Namely, Weblogic should be adding a
SAML ValueType attribute to the Reference inside the
SecurityTokenReference, and also it should be adding the SAML Token above
the Signature. Either of those two things would have solved the problem.
Colm.
On Thu, Nov 15, 2012 at 9:25 AM, andreas_triebel
<an...@adesso.ch>wrote:
> An iterop scenario with Weblogic as service consumer and Apache CXF (on
> JBoss) as service provider fails with a "Referenced security token could
> not
> be retrieved" error.
> The referenced security token (SAML assertion) is in place (Reference
> "#_0x1f0b85b073c1b3ef9ff63f003b319270"), but CXF cannot resolve it.
>
> Stacktrace:
> 09:00:25,035 WARNING [org.apache.cxf.phase.PhaseInterceptorChain]
> Interceptor for SAML2TestService#doit has thrown exception, unwinding now:
> org.apache.cxf.binding.soap.SoapFault: The signature or decryption was
> invalid
> at
>
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.createSoapFault(WSS4JInInterceptor.java:804)
> [jbossweb-7.0.13.Final.jar:]
> ...
> Caused by: org.apache.ws.security.WSSecurityException: The signature or
> decryption was invalid
> at
>
> org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:407)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.ws.security.processor.SignatureProcessor.handleToken(SignatureProcessor.java:197)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.ws.security.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:396)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessage(WSS4JInInterceptor.java:289)
> ... 26 more
> Caused by: javax.xml.crypto.dsig.XMLSignatureException:
> javax.xml.crypto.dsig.TransformException:
> org.apache.ws.security.WSSecurityException: Referenced security token could
> not be retrieved (Reference "#_0x1f0b85b073c1b3ef9ff63f003b319270")
> at
>
> org.apache.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:543)
> [xmlsec.jar:1.5.2]
> at
>
> org.apache.jcp.xml.dsig.internal.dom.DOMReference.validate(DOMReference.java:384)
> [xmlsec.jar:1.5.2]
> at
>
> org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.validate(DOMXMLSignature.java:267)
> [xmlsec.jar:1.5.2]
> at
>
> org.apache.ws.security.processor.SignatureProcessor.verifyXMLSignature(SignatureProcessor.java:380)
> [wss4j.jar:1.6.7]
> ... 29 more
> Caused by: javax.xml.crypto.dsig.TransformException:
> org.apache.ws.security.WSSecurityException: Referenced security token could
> not be retrieved (Reference "#_0x1f0b85b073c1b3ef9ff63f003b319270")
> at
>
> org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:274)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.ws.security.transform.STRTransform.transform(STRTransform.java:127)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.jcp.xml.dsig.internal.dom.DOMTransform.transform(DOMTransform.java:166)
> [xmlsec.jar:1.5.2]
> at
>
> org.apache.jcp.xml.dsig.internal.dom.DOMReference.transform(DOMReference.java:458)
> [xmlsec.jar:1.5.2]
> ... 32 more
> Caused by: org.apache.ws.security.WSSecurityException: Referenced security
> token could not be retrieved (Reference
> "#_0x1f0b85b073c1b3ef9ff63f003b319270")
> at
>
> org.apache.ws.security.message.token.SecurityTokenReference.getTokenElement(SecurityTokenReference.java:235)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.ws.security.transform.STRTransformUtil.dereferenceSTR(STRTransformUtil.java:69)
> [wss4j.jar:1.6.7]
> at
>
> org.apache.ws.security.transform.STRTransform.transformIt(STRTransform.java:200)
> [wss4j.jar:1.6.7]
> ... 35 more
>
>
> SOAP message:
> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
> <S:Header>
> ...
> <wsse:Security
>
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> S:mustUnderstand="1">
> ...
> <dsig:Signature xmlns:dsig="
> http://www.w3.org/2000/09/xmldsig#">
> <dsig:SignedInfo>
> <dsig:CanonicalizationMethod
> Algorithm="
> http://www.w3.org/2001/10/xml-exc-c14n#" />
> <dsig:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
> <dsig:Reference
> URI="#str_rF7CzO4LdKFt5zs6">
> <dsig:Transforms>
> <dsig:Transform
>
> Algorithm="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#STR-Transform
> ">
>
> <wsse:TransformationParameters>
>
> <dsig:CanonicalizationMethod
>
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
>
> </wsse:TransformationParameters>
> </dsig:Transform>
> </dsig:Transforms>
> <dsig:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
> />
>
> <dsig:DigestValue>iRkzoWPRp+m7x3v9JqX3Q/HdqYU=</dsig:DigestValue>
> </dsig:Reference>
> ...
> </dsig:SignedInfo>
>
> <dsig:SignatureValue>...</dsig:SignatureValue>
> <dsig:KeyInfo>...</dsig:KeyInfo>
> </dsig:Signature>
> <saml:Assertion
> xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
> ID="_0x1f0b85b073c1b3ef9ff63f003b319270"
> IssueInstant="2012-11-15T08:00:24.879Z"
> Version="2.0">
> ...
> </saml:Assertion>
> <wsse:SecurityTokenReference
>
> TokenType="
> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
> wsu:Id="str_rF7CzO4LdKFt5zs6">
> <wsse:Reference
> URI="#_0x1f0b85b073c1b3ef9ff63f003b319270" />
> </wsse:SecurityTokenReference>
> <wsu:Timestamp>
> ...
> </wsu:Timestamp>
> </wsse:Security>
> </S:Header>
> <S:Body>
> ...
> </S:Body>
> </S:Envelope>
>
>
> What I see is a difference between Weblogic and CXF generated
> SecurityTokenReference referencing the SAML assertion.
> Is this the issue and how could it be resolved? Any suggestions
> appreciated.
>
> Weblogic:
> <wsse:SecurityTokenReference
>
> TokenType="
> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
> wsu:Id="str_rF7CzO4LdKFt5zs6">
> <wsse:Reference URI="#_0x1f0b85b073c1b3ef9ff63f003b319270" />
> </wsse:SecurityTokenReference>
>
> CXF:
> <wsse:SecurityTokenReference
> xmlns:wsse11="
> http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"
> wsse11:TokenType="
> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0"
> wsu:Id="STR-C4F98A4E3E98FE682A135290662529414">
> <wsse:KeyIdentifier
>
> ValueType="
> http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID
> ">_C4F98A4E3E98FE682A135290662529213</wsse:KeyIdentifier>
> </wsse:SecurityTokenReference>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Signature-Interop-Issue-Weblogic-Apache-CXF-tp5718487.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com