Discussion:
WSsecurity: SignatureMethod error
Enrique Soriano
2016-03-08 13:40:27 UTC
Permalink
Hi all, I need some help with Axis2/rampart.

I'm implementing a WS client. I generated the client stubs from a WSDL
file by using wsdl2java (jaxbri binding). The WSDL file includes a
WS-security policy, which sets TripleDesSha256Rsa15 as the
AlgorithmSuite.

Rampart is engaged, my Keystore is ok, and so on. The problem: the
requests are signed with RsaSha256, but the server requires RsaSha1
signatures:

...
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
...

AFAIK, WS-SecurityPolicy specifies that RsaSha1 is always used for the
signatures. The AlgorithmSuite (e.g. TripleDesSha256Rsa15) is used to
configure the other crypto algorithms (digest, symmetric, wrapping,
etc.), right?

What's happening here? Am I missing something?

I'm using Java 1.8, axis2-1.7.1, rampart-1.7.0 and wss4j-1.6.19.

Thanks in advance.
Regards.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-***@axis.apache.org
For additional commands, e-mail: java-user-***@axis.apache.org
Martin Gainty
2016-03-09 01:57:47 UTC
Permalink
Date: Tue, 8 Mar 2016 14:40:27 +0100
Subject: WSsecurity: SignatureMethod error
Hi all, I need some help with Axis2/rampart.
I'm implementing a WS client. I generated the client stubs from a WSDL
file by using wsdl2java (jaxbri binding). The WSDL file includes a
WS-security policy, which sets TripleDesSha256Rsa15 as the
AlgorithmSuite.
Rampart is engaged, my Keystore is ok, and so on. The problem: the
requests are signed with RsaSha256, but the server requires RsaSha1
MG>constrained by MG><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#MG>which is of type anyURI <attribute name="Algorithm" type="anyURI" use="required"/>
MG>anyURI is defined as3.2.17 anyURI[Definition:] anyURI represents a Uniform Resource Identifier Reference (URI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be a URI Reference). This type should be used to specify the intention that the value fulfills the role of a URI as defined by [RFC 2396], as amended by [RFC 2732].The mapping from anyURI values to URIs is as defined in Section 5.4 Locator Attribute of [XML Linking Language] (see also Section 8 Character Encoding in URI References of [Character Model]). This means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC 2396], as amended by[RFC 2732], where appropriate to identify resources.NOTE: Each URI scheme imposes specialized syntax rules for URIs in that scheme, including restrictions on the syntax of allowed fragement identifiers. Because it is impractical for processors to check that a value is a context-appropriate URI reference, this specification follows the lead of [RFC 2396] (as amended by [RFC 2732]) in this matter: such rules and restrictions are not part of type validity and are not checked by ·minimally conforming· processors. Thus in practice the above definition imposes only very modest obligations on·minimally conforming· processors.3.2.17.1 Lexical representationThe ·lexical space· of anyURI is finite-length character sequences which, when the algorithm defined in Section 5.4 of [XML Linking Language] is applied to them, result in strings which are legal URIs according to [RFC 2396], as amended by [RFC 2732].
NOTE: Spaces are, in principle, allowed in the ·lexical space· of anyURI, however, their use is highly discouraged (unless they are encoded by %20).3.2.17.2 Constraining facetsanyURI has the following ·constraining facets·:
lengthminLengthmaxLengthpatternenumerationwhiteSpaceMG>
...
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
...
AFAIK, WS-SecurityPolicy specifies that RsaSha1 is always used for the
signatures. The AlgorithmSuite (e.g. TripleDesSha256Rsa15) is used to
configure the other crypto algorithms (digest, symmetric, wrapping,
etc.), right?
MG>so as long as http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 conforms to anyURI type that should workMG>which specific algorithm do you want to implement on the server?
What's happening here? Am I missing something?
I'm using Java 1.8, axis2-1.7.1, rampart-1.7.0 and wss4j-1.6.19.
Thanks in advance.
Regards.
---------------------------------------------------------------------
Enrique Soriano
2016-03-09 08:39:38 UTC
Permalink
First of all, thanks for the prompt response.
Post by Martin Gainty
Post by Martin Gainty
which specific algorithm do you want to implement on the server?
I'm trying to implement a client for an existing server. The server
only accepts rsa-sha1 signatures.
I can't read or modify the server code, I only have the WSDL to
generate the client stubs.

How can I force the client to use http://www.w3.org/2000/09/xmldsig#rsa-sha1?

Thanks.
Post by Martin Gainty
Date: Tue, 8 Mar 2016 14:40:27 +0100
Subject: WSsecurity: SignatureMethod error
Hi all, I need some help with Axis2/rampart.
I'm implementing a WS client. I generated the client stubs from a WSDL
file by using wsdl2java (jaxbri binding). The WSDL file includes a
WS-security policy, which sets TripleDesSha256Rsa15 as the
AlgorithmSuite.
Rampart is engaged, my Keystore is ok, and so on. The problem: the
requests are signed with RsaSha256, but the server requires RsaSha1
MG>constrained by
MG><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
MG>which is of type anyURI <attribute name="Algorithm" type="anyURI"
use="required"/>
MG>anyURI is defined as
3.2.17 anyURI
[Definition:] anyURI represents a Uniform Resource Identifier Reference
(URI). An anyURI value can be absolute or relative, and may have an optional
fragment identifier (i.e., it may be a URI Reference). This type should be
used to specify the intention that the value fulfills the role of a URI as
defined by [RFC 2396], as amended by [RFC 2732].
The mapping from anyURI values to URIs is as defined in Section 5.4 Locator
Attribute of [XML Linking Language] (see also Section 8 Character Encoding
in URI References of [Character Model]). This means that a wide range of
internationalized resource identifiers can be specified when an anyURI is
called for, and still be understood as URIs per [RFC 2396], as amended
by[RFC 2732], where appropriate to identify resources.
NOTE: Each URI scheme imposes specialized syntax rules for URIs in that
scheme, including restrictions on the syntax of allowed fragement
identifiers. Because it is impractical for processors to check that a value
is a context-appropriate URI reference, this specification follows the lead
of [RFC 2396] (as amended by [RFC 2732]) in this matter: such rules and
restrictions are not part of type validity and are not checked by ·minimally
conforming· processors. Thus in practice the above definition imposes only
very modest obligations on·minimally conforming· processors.
3.2.17.1 Lexical representation
The ·lexical space· of anyURI is finite-length character sequences which,
when the algorithm defined in Section 5.4 of [XML Linking Language] is
applied to them, result in strings which are legal URIs according to [RFC
2396], as amended by [RFC 2732].
NOTE: Spaces are, in principle, allowed in the ·lexical space· of anyURI,
however, their use is highly discouraged (unless they are encoded by %20).
3.2.17.2 Constraining facets
length
minLength
maxLength
pattern
enumeration
whiteSpace
MG>
...
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
...
AFAIK, WS-SecurityPolicy specifies that RsaSha1 is always used for the
signatures. The AlgorithmSuite (e.g. TripleDesSha256Rsa15) is used to
configure the other crypto algorithms (digest, symmetric, wrapping,
etc.), right?
MG>so as long as http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 conforms
to anyURI type that should work
MG>which specific algorithm do you want to implement on the server?
What's happening here? Am I missing something?
I'm using Java 1.8, axis2-1.7.1, rampart-1.7.0 and wss4j-1.6.19.
Thanks in advance.
Regards.
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-***@axis.apache.org
For additional commands, e-mail: java-user-***@axis.apache.org
Martin Gainty
2016-03-09 14:34:32 UTC
Permalink
2000 spec you are currently implementing:<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

does not acommodate 256 bit signatures
your current option will only allow 2000 xmldsig spec which is why you are defaulting to rsa-sha1 algorithm in SignatureMethod

<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
take a look at default policy declaration in services.xml for your deployed service:
<!--- wsp:Policy wsu:Id="SigEncr" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" -->
<!-- replace with --><wsp:Policy wsu:Id="SigEncr" <!-- same -->
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" <!-- same --> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" <!-- add this -->

xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" > <!-- same --> <wsp:ExactlyOne> <wsp:All> <sp:AsymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:InitiatorToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> <wsp:Policy> <!-- sp:WssX509V3Token10/ --> <!-- comment out any other algo --> <!-- here are Algorithm options for 2005-07 spec <wsp:Policy xmlns:wsp="..."> (<sp:Basic256 ... /> | <sp:Basic192 ... /> | <sp:Basic128 ... /> | <sp:TripleDes ... /> | <sp:Basic256Rsa15 ... /> | <sp:Basic192Rsa15 ... /> | <sp:Basic128Rsa15 ... /> | <sp:TripleDesRsa15 ... /> | <sp:Basic256Sha256 ... /> | <sp:Basic192Sha256 ... /> | <sp:Basic128Sha256 ... /> | <sp:TripleDesSha256 ... /> | <sp:Basic256Sha256Rsa15 ... /> | <sp:Basic192Sha256Rsa15 ... /> | <sp:Basic128Sha256Rsa15 ... /> | <sp:TripleDesSha256Rsa15 ... /> | ...) <sp:InclusiveC14N ... /> ? <sp:SOAPNormalization10 ... /> ? <sp:STRTransform10 ... /> ? (<sp:XPath10 ... /> | <sp:XPathFilter20 ... /> | <sp:AbsXPath ... / --> <sp:Basic256Rsa15 /> <!-- my suggestion --> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorToken> <sp:RecipientToken> <wsp:Policy> <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never"> <wsp:Policy> <!-- sp:WssX509V3Token10/ --> <!-- comment out other algos --> <!-- here are options for 2005-07 spec <wsp:Policy xmlns:wsp="..."> (<sp:Basic256 ... /> | <sp:Basic192 ... /> | <sp:Basic128 ... /> | <sp:TripleDes ... /> | <sp:Basic256Rsa15 ... /> | <sp:Basic192Rsa15 ... /> | <sp:Basic128Rsa15 ... /> | <sp:TripleDesRsa15 ... /> | <sp:Basic256Sha256 ... /> | <sp:Basic192Sha256 ... /> | <sp:Basic128Sha256 ... /> | <sp:TripleDesSha256 ... /> | <sp:Basic256Sha256Rsa15 ... /> | <sp:Basic192Sha256Rsa15 ... /> | <sp:Basic128Sha256Rsa15 ... /> | <sp:TripleDesSha256Rsa15 ... /> | ...) <sp:InclusiveC14N ... /> ? <sp:SOAPNormalization10 ... /> ? <sp:STRTransform10 ... /> ? (<sp:XPath10 ... /> | <sp:XPathFilter20 ... /> | <sp:AbsXPath ... / --> <sp:Basic256Rsa15 /> <!-- my suggestion although Asymmetric recipient can be different from initiator --> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientToken> <sp:AlgorithmSuite> <wsp:Policy> <!-- sp:Basic128/ --> <!-- comment out other algos --> <sp:Basic256Rsa15 /> <!-- my suggestion although Asymmetric recipient can be different from initiator --> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Strict/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <wsp:Policy> <sp:MustSupportRefKeyIdentifier/> <sp:MustSupportRefIssuerSerial/> </wsp:Policy> </sp:Wss10> <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/> </sp:SignedParts> <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"> <sp:Body/> </sp:EncryptedParts> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"> <ramp:user>ip</ramp:user> <!-- needs to be actual user --> <ramp:encryptionUser>useReqSigCert</ramp:encryptionUser> <ramp:passwordCallbackClass>org.apache.rahas.PWCallback</ramp:passwordCallbackClass> <!-- assume Callback is coded? --> <ramp:signatureCrypto> <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin"> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property> <ramp:property name="org.apache.ws.security.crypto.merlin.file">rahas-sts.jks</ramp:property> <!-- verify valid jks on classpath --> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">password</ramp:property><!-- needs to be actual password to keystore --> </ramp:crypto> </ramp:signatureCrypto><ramp:encryptionCypto> <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin"> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property> <ramp:property name="org.apache.ws.security.crypto.merlin.file">rahas-sts.jks</ramp:property> <!-- verify valid jks on classpath --> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">password</ramp:property>
<!-- needs to be actual password to keystore --> </ramp:crypto> </ramp:encryptionCypto> </ramp:RampartConfig> </wsp:All> </wsp:ExactlyOne> </wsp:Policy>
I will assume this Policy declaration is already in your WSDL?
recreate server code>wsdl2java -ss -g -uri test.wsdl
if you dont have services.xml and want to generate services.xml>wsdl2java -ss -g -sd -uri test.wsdl
jar server>ant jar.server
use axis2 admin upload utility to upload .\build\lib\*.aar to axis2 webserviceyou should now see the service deployed and all operations displayed

jar client>ant jar.client
run client jar>java jar /lib/test-test-client.jar

what do you see?Martin
______________________________________________
Date: Wed, 9 Mar 2016 09:39:38 +0100
Subject: Re: WSsecurity: SignatureMethod error
First of all, thanks for the prompt response.
Post by Martin Gainty
Post by Martin Gainty
which specific algorithm do you want to implement on the server?
I'm trying to implement a client for an existing server. The server
only accepts rsa-sha1 signatures.
I can't read or modify the server code, I only have the WSDL to
generate the client stubs.
How can I force the client to use http://www.w3.org/2000/09/xmldsig#rsa-sha1?
Thanks.
Post by Martin Gainty
Date: Tue, 8 Mar 2016 14:40:27 +0100
Subject: WSsecurity: SignatureMethod error
Hi all, I need some help with Axis2/rampart.
I'm implementing a WS client. I generated the client stubs from a WSDL
file by using wsdl2java (jaxbri binding). The WSDL file includes a
WS-security policy, which sets TripleDesSha256Rsa15 as the
AlgorithmSuite.
Rampart is engaged, my Keystore is ok, and so on. The problem: the
requests are signed with RsaSha256, but the server requires RsaSha1
MG>constrained by
MG><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#
MG>which is of type anyURI <attribute name="Algorithm" type="anyURI"
use="required"/>
MG>anyURI is defined as
3.2.17 anyURI
[Definition:] anyURI represents a Uniform Resource Identifier Reference
(URI). An anyURI value can be absolute or relative, and may have an optional
fragment identifier (i.e., it may be a URI Reference). This type should be
used to specify the intention that the value fulfills the role of a URI as
defined by [RFC 2396], as amended by [RFC 2732].
The mapping from anyURI values to URIs is as defined in Section 5.4 Locator
Attribute of [XML Linking Language] (see also Section 8 Character Encoding
in URI References of [Character Model]). This means that a wide range of
internationalized resource identifiers can be specified when an anyURI is
called for, and still be understood as URIs per [RFC 2396], as amended
by[RFC 2732], where appropriate to identify resources.
NOTE: Each URI scheme imposes specialized syntax rules for URIs in that
scheme, including restrictions on the syntax of allowed fragement
identifiers. Because it is impractical for processors to check that a value
is a context-appropriate URI reference, this specification follows the lead
of [RFC 2396] (as amended by [RFC 2732]) in this matter: such rules and
restrictions are not part of type validity and are not checked by ·minimally
conforming· processors. Thus in practice the above definition imposes only
very modest obligations on·minimally conforming· processors.
3.2.17.1 Lexical representation
The ·lexical space· of anyURI is finite-length character sequences which,
when the algorithm defined in Section 5.4 of [XML Linking Language] is
applied to them, result in strings which are legal URIs according to [RFC
2396], as amended by [RFC 2732].
NOTE: Spaces are, in principle, allowed in the ·lexical space· of anyURI,
however, their use is highly discouraged (unless they are encoded by %20).
3.2.17.2 Constraining facets
length
minLength
maxLength
pattern
enumeration
whiteSpace
MG>
...
<ds:SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
...
AFAIK, WS-SecurityPolicy specifies that RsaSha1 is always used for the
signatures. The AlgorithmSuite (e.g. TripleDesSha256Rsa15) is used to
configure the other crypto algorithms (digest, symmetric, wrapping,
etc.), right?
MG>so as long as http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 conforms
to anyURI type that should work
MG>which specific algorithm do you want to implement on the server?
What's happening here? Am I missing something?
I'm using Java 1.8, axis2-1.7.1, rampart-1.7.0 and wss4j-1.6.19.
Thanks in advance.
Regards.
---------------------------------------------------------------------
---------------------------------------------------------------------
Enrique Soriano
2016-03-09 18:34:04 UTC
Permalink
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).

Regards.
Martin Gainty
2016-03-10 13:31:09 UTC
Permalink
Item1:

SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html

Item2: <sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>notice that AlgorithmSuite sp:Basic128 is common to both initiator and recipient
how would client signing with rsa-sha1 algorithm be able to communicate with any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________



Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the signature method my client is currently using).
Regards.
Enrique Soriano
2016-03-10 14:57:11 UTC
Permalink
Hi Martin, thanks for your response (again).

I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.

Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.

According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.

Regards.
Enrique

Refs:

[1] https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html

[2] http://cxf.apache.org/docs/ws-securitypolicy.html
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to communicate with
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-***@axis.apache.org
For additional commands, e-mail: java-user-***@axis.apache.org
Martin Gainty
2016-03-11 12:56:34 UTC
Permalink
for my understanding and to be clear
1)you are not implementing rsa-sha256 on Initiator or recipient so the rsa-sha256 question is a no-op

2)you are not implementing EncryptedKeySHA1 which is for encryption/decryption only

3)if the web-service is implementing rsa-sha1
Martin Gainty
______________________________________________
_____ _ _____ _ _____ ___ _ _____ _ _ _
|_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___
| | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | |
|_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_|
|_|
Date: Thu, 10 Mar 2016 15:57:11 +0100
Subject: Re: WSsecurity: SignatureMethod error
Hi Martin, thanks for your response (again).
I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.
Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.
According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.
Regards.
Enrique
[1] https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
MG>this is what Fuse supports..one work around is to implement with Apache ESB which supports OASIS spec
MG>speaking of which ..lets reference the OASIS spec on Asymmetric Binding to make sure we are on the same page
MG>if for no other reason than 99% of Financial Institutions only implement X509 tokens..so if your implementation
MG>does not support X509 you wont be able to implement in majority of financial institutions
MG>below is a verbatim parroting of OASIS spec:
C.3.1 PolicyThe following example shows a policy indicating an Asymmetric Binding,
an X509 token as the [Initiator Token],
an X509 token as the [Recipient Token],
an algorithm suite, a requirement to encrypt the message parts before signing,
a requirement to encrypt the message signature,
a requirement to include tokens in the message signature and the supporting signatures,
a requirement to include wsse11:SignatureConfirmation elements,
a username token attached to the message, and finally an X509 token attached to the message and endorsing the message signature.
Minimum message protection requirements are described as well.<!-- Example Endpoint Policy -->
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:RecipientToken>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:EncryptSignature />
<sp:ProtectTokens />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Once"> <wsp:Policy> <sp:WssX509v3Token10 /> </wsp:Policy> </sp:X509Token>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>

<!-- Example Message Policy -->
<wsp:All xmlns:wsp="..." xmlns:sp="...">
<sp:SignedParts>
<sp:Header Name="Header1" Namespace="..." />
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature encryption is wrong?
<sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite>
MG>Jboss Fuse requirements states there is no algorithm other than dsa-rsa1 supported?
MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256
MG>is OASIS incorrect?
TheWS-SecurityPolicy specification allows for specifying things like asymmetric/symmetric keys, using transports (https) for encryption, which parts/headers to encrypt or sign, whether to sign then encrypt or encrypt then sign, whether to include timestamps, whether to use derived keys, etc... Basically, it describes what actions are necessary to securely interact with the service described in the WSDL.

MG>Additional Note: does CXF tell you that if you use camelcase names for ComplexElements you will fubar CXF wsdl2java?
MG>i have a 4 year old string of emails that documents this fatal error
MG>CONCLUSION
MG>take everything you read from vendors with a grain of salt
MG>its is always a good idea to go back to the original specification for the source of truth
MG>Saludos Enrique
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to communicate with
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
Enrique Soriano
2016-03-11 15:55:17 UTC
Permalink
Hi Martin, I really appreciate your efforts to help me, but I think you
didn’t understand the problem.

The client stubs generated by Axis2 1.7.1 were sending rsa-sha256
signatures, this is a fact.

The server I need to use requires rsa-sha1 signatures, this is a fact.

The client stubs generated by Axis2 1.6.4 are sending rsa-sha1 signatures,
this is a fact.

The client and the server can *now* verify the request/responses, this is a
fact.

My question was not a no-op.


Thanks again.
Regards.
Post by Martin Gainty
for my understanding and to be clear
1)you are not implementing rsa-sha256 on Initiator or recipient so the
rsa-sha256 question is a no-op
2)you are not implementing EncryptedKeySHA1 which is for
encryption/decryption only
3)if the web-service is implementing rsa-sha1
Martin Gainty
______________________________________________
_____ _ _____ _ _____ ___ _ _____ _ _ _
|_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___
| | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | |
|_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_|
|_|
Date: Thu, 10 Mar 2016 15:57:11 +0100
Subject: Re: WSsecurity: SignatureMethod error
Hi Martin, thanks for your response (again).
I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.
Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to
communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.
According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.
Regards.
Enrique
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
MG>this is what Fuse supports..one work around is to implement with Apache
ESB which supports OASIS spec
MG>speaking of which ..lets reference the OASIS spec on Asymmetric Binding
to make sure we are on the same page
MG>if for no other reason than 99% of Financial Institutions only
implement X509 tokens..so if your implementation
MG>does not support X509 you wont be able to implement in majority of
financial institutions
C.3.1 Policy
The following example shows a policy indicating an Asymmetric Binding,
an X509 token as the [Initiator Token],
an X509 token as the [Recipient Token],
an algorithm suite, a requirement to encrypt the message parts before signing,
a requirement to encrypt the message signature,
a requirement to include tokens in the message signature and the supporting signatures,
a requirement to include wsse11:SignatureConfirmation elements,
a username token attached to the message, and finally an X509 token
attached to the message and endorsing the message signature.
Minimum message protection requirements are described as well.
<!-- Example Endpoint Policy -->
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:RecipientToken>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:EncryptSignature />
<sp:ProtectTokens />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Once">
<wsp:Policy>
<sp:WssX509v3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
<!-- Example Message Policy -->
<wsp:All xmlns:wsp="..." xmlns:sp="...">
<sp:SignedParts>
<sp:Header Name="Header1" Namespace="..." />
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature encryption is wrong?
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
MG>Jboss Fuse requirements states there is no algorithm other than dsa-rsa1 supported?
MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256
MG>is OASIS incorrect?
[2] http://cxf.apache.org/docs/ws-securitypolicy.html
MG>assertions are misleading but the CYA statement is DOB accurate when
TheWS-SecurityPolicy specification
<http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws-securitypolicy.html> allows
for specifying things like asymmetric/symmetric keys, using transports
(https) for encryption, which parts/headers to encrypt or sign, whether to
sign then encrypt or encrypt then sign, whether to include timestamps,
whether to use derived keys, etc... Basically, it describes what actions
are necessary to securely interact with the service described in the WSDL.
MG>Additional Note: does CXF tell you that if you use camelcase names for
ComplexElements you will fubar CXF wsdl2java?
MG>i have a 4 year old string of emails that documents this fatal error
MG>CONCLUSION
MG>take everything you read from vendors with a grain of salt
MG>its is always a good idea to go back to the original specification for
the source of truth
MG>Saludos Enrique
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to
communicate with
Post by Martin Gainty
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
Andreas Veithen
2016-03-11 18:39:13 UTC
Permalink
I looked at the version history and the following commit seems to be
related:

http://svn.apache.org/viewvc?rev=1087600&view=rev

Maybe that's the change between 1.6.4 and 1.7.0 that explains your issue.

Andreas
Post by Enrique Soriano
Hi Martin, I really appreciate your efforts to help me, but I think you
didn’t understand the problem.
The client stubs generated by Axis2 1.7.1 were sending rsa-sha256
signatures, this is a fact.
The server I need to use requires rsa-sha1 signatures, this is a fact.
The client stubs generated by Axis2 1.6.4 are sending rsa-sha1 signatures,
this is a fact.
The client and the server can *now* verify the request/responses, this is
a fact.
My question was not a no-op.
Thanks again.
Regards.
Post by Martin Gainty
for my understanding and to be clear
1)you are not implementing rsa-sha256 on Initiator or recipient so the
rsa-sha256 question is a no-op
2)you are not implementing EncryptedKeySHA1 which is for
encryption/decryption only
3)if the web-service is implementing rsa-sha1
Martin Gainty
______________________________________________
_____ _ _____ _ _____ ___ _ _____ _ _ _
|_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___
| | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | |
|_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_|
|_|
Date: Thu, 10 Mar 2016 15:57:11 +0100
Subject: Re: WSsecurity: SignatureMethod error
Hi Martin, thanks for your response (again).
I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.
Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to
communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.
According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.
Regards.
Enrique
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
MG>this is what Fuse supports..one work around is to implement with
Apache ESB which supports OASIS spec
MG>speaking of which ..lets reference the OASIS spec on Asymmetric
Binding to make sure we are on the same page
MG>if for no other reason than 99% of Financial Institutions only
implement X509 tokens..so if your implementation
MG>does not support X509 you wont be able to implement in majority of
financial institutions
C.3.1 Policy
The following example shows a policy indicating an Asymmetric Binding,
an X509 token as the [Initiator Token],
an X509 token as the [Recipient Token],
an algorithm suite, a requirement to encrypt the message parts before signing,
a requirement to encrypt the message signature,
a requirement to include tokens in the message signature and the supporting signatures,
a requirement to include wsse11:SignatureConfirmation elements,
a username token attached to the message, and finally an X509 token
attached to the message and endorsing the message signature.
Minimum message protection requirements are described as well.
<!-- Example Endpoint Policy -->
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:RecipientToken>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:EncryptSignature />
<sp:ProtectTokens />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Once">
<wsp:Policy>
<sp:WssX509v3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
<!-- Example Message Policy -->
<wsp:All xmlns:wsp="..." xmlns:sp="...">
<sp:SignedParts>
<sp:Header Name="Header1" Namespace="..." />
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature encryption is wrong?
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
MG>Jboss Fuse requirements states there is no algorithm other than dsa-rsa1 supported?
MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256
MG>is OASIS incorrect?
[2] http://cxf.apache.org/docs/ws-securitypolicy.html
MG>assertions are misleading but the CYA statement is DOB accurate when
TheWS-SecurityPolicy specification
<http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws-securitypolicy.html> allows
for specifying things like asymmetric/symmetric keys, using transports
(https) for encryption, which parts/headers to encrypt or sign, whether to
sign then encrypt or encrypt then sign, whether to include timestamps,
whether to use derived keys, etc... Basically, it describes what actions
are necessary to securely interact with the service described in the WSDL.
MG>Additional Note: does CXF tell you that if you use camelcase names for
ComplexElements you will fubar CXF wsdl2java?
MG>i have a 4 year old string of emails that documents this fatal error
MG>CONCLUSION
MG>take everything you read from vendors with a grain of salt
MG>its is always a good idea to go back to the original specification for
the source of truth
MG>Saludos Enrique
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
Post by Martin Gainty
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to
communicate with
Post by Martin Gainty
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
Martin Gainty
2016-03-12 01:16:28 UTC
Permalink
On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <***@gmail.com> wrote:
Hi Martin, I really appreciate your efforts to help me, but I think you didn’t understand the problem.
The client stubs generated by Axis2 1.7.1 were sending rsa-sha256 signatures, this is a fact.

MG>faux pas as you should be posting version specific bugs at https://issues.apache.org/jira/browse/AXIS2MG>for your edification dont use this email list for one off version specific possible bugs
MG>this is for versions that have already been released not for issues on new (unreleased) versions are addressed here
MG>nobody could track the version you were implementing as you were always assuming we knew
MG>In the future watch your denigrating tone, dont assume we know what version you are using
MF>obey the rules and you should be ok if not you be will ignored MG>adios

The server I need to use requires rsa-sha1 signatures, this is a fact.
The client stubs generated by Axis2 1.6.4 are sending rsa-sha1 signatures, this is a fact.
The client and the server can *now* verify the request/responses, this is a fact.
My question was not a no-op.
Thanks again.Regards.
On Fri, Mar 11, 2016 at 1:56 PM, Martin Gainty <***@hotmail.com> wrote:



for my understanding and to be clear
1)you are not implementing rsa-sha256 on Initiator or recipient so the rsa-sha256 question is a no-op

2)you are not implementing EncryptedKeySHA1 which is for encryption/decryption only

3)if the web-service is implementing rsa-sha1
Martin Gainty
______________________________________________
_____ _ _____ _ _____ ___ _ _____ _ _ _
|_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___
| | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | |
|_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_|
|_|
Date: Thu, 10 Mar 2016 15:57:11 +0100
Subject: Re: WSsecurity: SignatureMethod error
Hi Martin, thanks for your response (again).
I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.
Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.
According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.
Regards.
Enrique
[1] https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
MG>this is what Fuse supports..one work around is to implement with Apache ESB which supports OASIS spec
MG>speaking of which ..lets reference the OASIS spec on Asymmetric Binding to make sure we are on the same page
MG>if for no other reason than 99% of Financial Institutions only implement X509 tokens..so if your implementation
MG>does not support X509 you wont be able to implement in majority of financial institutions
MG>below is a verbatim parroting of OASIS spec:
C.3.1 PolicyThe following example shows a policy indicating an Asymmetric Binding,
an X509 token as the [Initiator Token],
an X509 token as the [Recipient Token],
an algorithm suite, a requirement to encrypt the message parts before signing,
a requirement to encrypt the message signature,
a requirement to include tokens in the message signature and the supporting signatures,
a requirement to include wsse11:SignatureConfirmation elements,
a username token attached to the message, and finally an X509 token attached to the message and endorsing the message signature.
Minimum message protection requirements are described as well.<!-- Example Endpoint Policy -->
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:RecipientToken>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:EncryptSignature />
<sp:ProtectTokens />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Once"> <wsp:Policy> <sp:WssX509v3Token10 /> </wsp:Policy> </sp:X509Token>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>

<!-- Example Message Policy -->
<wsp:All xmlns:wsp="..." xmlns:sp="...">
<sp:SignedParts>
<sp:Header Name="Header1" Namespace="..." />
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature encryption is wrong?
<sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256 /> </wsp:Policy> </sp:AlgorithmSuite>
MG>Jboss Fuse requirements states there is no algorithm other than dsa-rsa1 supported?
MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256
MG>is OASIS incorrect?
TheWS-SecurityPolicy specification allows for specifying things like asymmetric/symmetric keys, using transports (https) for encryption, which parts/headers to encrypt or sign, whether to sign then encrypt or encrypt then sign, whether to include timestamps, whether to use derived keys, etc... Basically, it describes what actions are necessary to securely interact with the service described in the WSDL.

MG>Additional Note: does CXF tell you that if you use camelcase names for ComplexElements you will fubar CXF wsdl2java?
MG>i have a 4 year old string of emails that documents this fatal error
MG>CONCLUSION
MG>take everything you read from vendors with a grain of salt
MG>its is always a good idea to go back to the original specification for the source of truth
MG>Saludos Enrique
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to communicate with
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
Enrique Soriano
2016-03-12 09:15:12 UTC
Permalink
Martin, read the thread again. Did you read the first mail?

I specified the problem in the first mail (including the versions). I was
asking for help, I was not posting a bug (I didn't know it could be a bug).

Your answers were confusing. I had to tell you that I wanted to use
rsa-sha1 signatures for *three times*.

Denigrating tone? You said my question is no-op. I've been quite polite so
far.

Just a suggestion: if you want to help, please try to read and understand
the questions. Otherwise, it's just empty bragging.

Thanks for your time (again).
Regards.
Post by Martin Gainty
On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <
Hi Martin, I really appreciate your efforts to help me, but I think you
didn’t understand the problem.
The client stubs generated by Axis2 1.7.1 were sending rsa-sha256
signatures, this is a fact.
MG>faux pas as you should be posting version specific bugs at
https://issues.apache.org/jira/browse/AXIS2
MG>for your edification dont use this email list for one off version
specific possible bugs
MG>this is for versions that have already been released not for issues on
new (unreleased) versions are addressed here
MG>nobody could track the version you were implementing as you were always assuming we knew
MG>In the future watch your denigrating tone, dont assume we know what
version you are using
MF>obey the rules and you should be ok if not you be will ignored MG>adios
The server I need to use requires rsa-sha1 signatures, this is a fact.
The client stubs generated by Axis2 1.6.4 are sending rsa-sha1 signatures, this is a fact.
The client and the server can *now* verify the request/responses, this is a fact.
My question was not a no-op.
Thanks again.
Regards.
for my understanding and to be clear
1)you are not implementing rsa-sha256 on Initiator or recipient so the
rsa-sha256 question is a no-op
2)you are not implementing EncryptedKeySHA1 which is for
encryption/decryption only
3)if the web-service is implementing rsa-sha1
Martin Gainty
______________________________________________
_____ _ _____ _ _____ ___ _ _____ _ _ _
|_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___
| | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | |
|_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_|
|_|
Date: Thu, 10 Mar 2016 15:57:11 +0100
Subject: Re: WSsecurity: SignatureMethod error
Hi Martin, thanks for your response (again).
I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.
Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to
communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.
According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.
Regards.
Enrique
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
MG>this is what Fuse supports..one work around is to implement with Apache
ESB which supports OASIS spec
MG>speaking of which ..lets reference the OASIS spec on Asymmetric Binding
to make sure we are on the same page
MG>if for no other reason than 99% of Financial Institutions only
implement X509 tokens..so if your implementation
MG>does not support X509 you wont be able to implement in majority of
financial institutions
C.3.1 Policy
The following example shows a policy indicating an Asymmetric Binding,
an X509 token as the [Initiator Token],
an X509 token as the [Recipient Token],
an algorithm suite, a requirement to encrypt the message parts before signing,
a requirement to encrypt the message signature,
a requirement to include tokens in the message signature and the supporting signatures,
a requirement to include wsse11:SignatureConfirmation elements,
a username token attached to the message, and finally an X509 token
attached to the message and endorsing the message signature.
Minimum message protection requirements are described as well.
<!-- Example Endpoint Policy -->
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:RecipientToken>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:EncryptSignature />
<sp:ProtectTokens />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Once">
<wsp:Policy>
<sp:WssX509v3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
<!-- Example Message Policy -->
<wsp:All xmlns:wsp="..." xmlns:sp="...">
<sp:SignedParts>
<sp:Header Name="Header1" Namespace="..." />
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature encryption is wrong?
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
MG>Jboss Fuse requirements states there is no algorithm other than dsa-rsa1 supported?
MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256
MG>is OASIS incorrect?
[2] http://cxf.apache.org/docs/ws-securitypolicy.html
MG>assertions are misleading but the CYA statement is DOB accurate when
TheWS-SecurityPolicy specification
<http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws-securitypolicy.html> allows
for specifying things like asymmetric/symmetric keys, using transports
(https) for encryption, which parts/headers to encrypt or sign, whether to
sign then encrypt or encrypt then sign, whether to include timestamps,
whether to use derived keys, etc... Basically, it describes what actions
are necessary to securely interact with the service described in the WSDL.
MG>Additional Note: does CXF tell you that if you use camelcase names for
ComplexElements you will fubar CXF wsdl2java?
MG>i have a 4 year old string of emails that documents this fatal error
MG>CONCLUSION
MG>take everything you read from vendors with a grain of salt
MG>its is always a good idea to go back to the original specification for
the source of truth
MG>Saludos Enrique
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to
communicate with
Post by Martin Gainty
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
Andreas Veithen
2016-03-12 09:53:36 UTC
Permalink
You should probably ignore Martin, he's just a troll. What I would do is to
build Rampart 1.7.0 (or 1.7.1-SNAPSHOT) from the sources with r1087600
removed, to check whether that change is responsible for the problem.

Andreas
Post by Enrique Soriano
Martin, read the thread again. Did you read the first mail?
I specified the problem in the first mail (including the versions). I was
asking for help, I was not posting a bug (I didn't know it could be a bug).
Your answers were confusing. I had to tell you that I wanted to use
rsa-sha1 signatures for *three times*.
Denigrating tone? You said my question is no-op. I've been quite polite so
far.
Just a suggestion: if you want to help, please try to read and understand
the questions. Otherwise, it's just empty bragging.
Thanks for your time (again).
Regards.
Post by Martin Gainty
On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <
Hi Martin, I really appreciate your efforts to help me, but I think you
didn’t understand the problem.
The client stubs generated by Axis2 1.7.1 were sending rsa-sha256
signatures, this is a fact.
MG>faux pas as you should be posting version specific bugs at
https://issues.apache.org/jira/browse/AXIS2
MG>for your edification dont use this email list for one off version
specific possible bugs
MG>this is for versions that have already been released not for issues on
new (unreleased) versions are addressed here
MG>nobody could track the version you were implementing as you were
always assuming we knew
MG>In the future watch your denigrating tone, dont assume we know what
version you are using
MF>obey the rules and you should be ok if not you be will ignored MG>adios
The server I need to use requires rsa-sha1 signatures, this is a fact.
The client stubs generated by Axis2 1.6.4 are sending rsa-sha1
signatures, this is a fact.
The client and the server can *now* verify the request/responses, this is a fact.
My question was not a no-op.
Thanks again.
Regards.
for my understanding and to be clear
1)you are not implementing rsa-sha256 on Initiator or recipient so the
rsa-sha256 question is a no-op
2)you are not implementing EncryptedKeySHA1 which is for
encryption/decryption only
3)if the web-service is implementing rsa-sha1
Martin Gainty
______________________________________________
_____ _ _____ _ _____ ___ _ _____ _ _ _
|_ _| |_ ___ | _ |___ ___ ___| |_ ___ | __|___| _| |_ _ _ _ ___ ___ ___ | __|___ _ _ ___ _| |___| |_|_|___ ___
| | | | -_| | | . | .'| _| | -_| |__ | . | _| _| | | | .'| _| -_| | __| . | | | | . | .'| _| | . | |
|_| |_|_|___| |__|__| _|__,|___|_|_|___| |_____|___|_| |_| |_____|__,|_| |___| |__| |___|___|_|_|___|__,|_| |_|___|_|_|
|_|
Date: Thu, 10 Mar 2016 15:57:11 +0100
Subject: Re: WSsecurity: SignatureMethod error
Hi Martin, thanks for your response (again).
I've solved the problem by downgrading to axis2-1.6.4. Now the client
stubs generated by wsdl2java work ok.
Maybe it's just a bug in Axis2 2-1.7.1 (??).
Post by Martin Gainty
Post by Martin Gainty
how would client signing with rsa-sha1 algorithm be able to
communicate with any webservice expecting rsa-sha256 signature?
This web service expects a rsa-sha1, as I said in previous messages.
According to [1] and [2], WS SecurityPolicy specifies that rsa-sha1
must be the signature algorithm. I'm not familiar with WS Security
anyway.
Regards.
Enrique
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Web_Services_Security_Guide/files/MsgProtect-SOAP-SpecifyAlgorithmSuite.html
MG>this is what Fuse supports..one work around is to implement with
Apache ESB which supports OASIS spec
MG>speaking of which ..lets reference the OASIS spec on Asymmetric
Binding to make sure we are on the same page
MG>if for no other reason than 99% of Financial Institutions only
implement X509 tokens..so if your implementation
MG>does not support X509 you wont be able to implement in majority of
financial institutions
C.3.1 Policy
The following example shows a policy indicating an Asymmetric Binding,
an X509 token as the [Initiator Token],
an X509 token as the [Recipient Token],
an algorithm suite, a requirement to encrypt the message parts before signing,
a requirement to encrypt the message signature,
a requirement to include tokens in the message signature and the supporting signatures,
a requirement to include wsse11:SignatureConfirmation elements,
a username token attached to the message, and finally an X509 token
attached to the message and endorsing the message signature.
Minimum message protection requirements are described as well.
<!-- Example Endpoint Policy -->
<wsp:Policy xmlns:wsp="..." xmlns:sp="...">
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:RecipientToken>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Always" />
</wsp:Policy>
</sp:InitiatorToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Strict />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:EncryptBeforeSigning />
<sp:EncryptSignature />
<sp:ProtectTokens />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:SignedEncryptedSupportingTokens>
<wsp:Policy>
<sp:UsernameToken sp:IncludeToken=".../IncludeToken/Once" />
</wsp:Policy>
</sp:SignedEncryptedSupportingTokens>
<sp:SignedEndorsingSupportingTokens>
<wsp:Policy>
<sp:X509Token sp:IncludeToken=".../IncludeToken/Once">
<wsp:Policy>
<sp:WssX509v3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:SignedEndorsingSupportingTokens>
<sp:Wss11>
<wsp:Policy>
<sp:RequireSignatureConfirmation />
</wsp:Policy>
</sp:Wss11>
</wsp:Policy>
<!-- Example Message Policy -->
<wsp:All xmlns:wsp="..." xmlns:sp="...">
<sp:SignedParts>
<sp:Header Name="Header1" Namespace="..." />
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:SignedParts>
<sp:EncryptedParts>
<sp:Header Name="Header2" Namespace="..." />
<sp:Body/>
</sp:EncryptedParts>
</wsp:All>
MG>by Jboss Fuse doc the Algorithm Suite sp:Basic256 for signature encryption is wrong?
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic256 />
</wsp:Policy>
</sp:AlgorithmSuite>
MG>Jboss Fuse requirements states there is no algorithm other than dsa-rsa1 supported?
MG>but OASIS standards DO support encryption of SIGNATURES with sp:Basic256
MG>is OASIS incorrect?
[2] http://cxf.apache.org/docs/ws-securitypolicy.html
MG>assertions are misleading but the CYA statement is DOB accurate when
TheWS-SecurityPolicy specification
<http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/ws-securitypolicy.html> allows
for specifying things like asymmetric/symmetric keys, using transports
(https) for encryption, which parts/headers to encrypt or sign, whether to
sign then encrypt or encrypt then sign, whether to include timestamps,
whether to use derived keys, etc... Basically, it describes what actions
are necessary to securely interact with the service described in the WSDL.
MG>Additional Note: does CXF tell you that if you use camelcase names for
ComplexElements you will fubar CXF wsdl2java?
MG>i have a 4 year old string of emails that documents this fatal error
MG>CONCLUSION
MG>take everything you read from vendors with a grain of salt
MG>its is always a good idea to go back to the original specification for
the source of truth
MG>Saludos Enrique
Post by Martin Gainty
SHA1 is used for encryption/decryption only
http://coheigea.blogspot.com/2013/03/signature-and-encryption-key.html
Post by Martin Gainty
<sp:AsymmetricBinding >
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
Post by Martin Gainty
<wsp:Policy>
<sp:WssX509V3Token10/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128/>
</wsp:Policy>
</sp:AlgorithmSuite>
notice that AlgorithmSuite sp:Basic128 is common to both initiator and
recipient
how would client signing with rsa-sha1 algorithm be able to
communicate with
Post by Martin Gainty
any webservice expecting rsa-sha256 signature?
Please explain
Martin
______________________________________________
________________________________
Date: Wed, 9 Mar 2016 19:34:04 +0100
Subject: RE: WSsecurity: SignatureMethod error
Post by Martin Gainty
2000 spec you are
<ds:KeyInfo xmlns:ds="http://
www.w3.org/2000/09/xmldsig#">
does not acommodate
256 bit signatures
your current option will only
allow 2000 xmldsig spec which is why
you are defaulting to rsa-sha1
algorithm in SignatureMethod
I want to use rsa-sha1, I don't want to use rsa-sha256 (which is the
signature method my client is currently using).
Regards.
---------------------------------------------------------------------
Loading...