WSsecurity: SignatureMethod error

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

WSsecurity: SignatureMethod error

Enrique Soriano
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: WSsecurity: SignatureMethod error

Martin Gainty





> Date: Tue, 8 Mar 2016 14:40:27 +0100

> Subject: WSsecurity: SignatureMethod error
> From: [hidden email]
> To: [hidden email]
>
> 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:
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
anyURI has the following ·constraining facets·:
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: WSsecurity: SignatureMethod error

Enrique Soriano
First of all, thanks for the prompt response.

>>>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.




On Wed, Mar 9, 2016 at 2:57 AM, Martin Gainty <[hidden email]> wrote:

>
>
>
>
>
>> Date: Tue, 8 Mar 2016 14:40:27 +0100
>> Subject: WSsecurity: SignatureMethod error
>> From: [hidden email]
>> To: [hidden email]
>>
>> 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:
>
> 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
>
> anyURI has the following ·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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: WSsecurity: SignatureMethod error

Martin Gainty
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 webservice
you 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
> From: [hidden email]
> To: [hidden email]
>
> First of all, thanks for the prompt response.
>
> >>>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.
>
>
>
>
> On Wed, Mar 9, 2016 at 2:57 AM, Martin Gainty <[hidden email]> wrote:
> >
> >
> >
> >
> >
> >> Date: Tue, 8 Mar 2016 14:40:27 +0100
> >> Subject: WSsecurity: SignatureMethod error
> >> From: [hidden email]
> >> To: [hidden email]
> >>
> >> 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:
> >
> > 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
> >
> > anyURI has the following ·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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

RE: WSsecurity: SignatureMethod error

Enrique Soriano


On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
>
> 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

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.

Reply | Threaded
Open this post in threaded view
|

RE: WSsecurity: SignatureMethod error

Martin Gainty
Item1:

SHA1 is used for encryption/decryption only

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
From: [hidden email]
To: [hidden email]


On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
>
> 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

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.

Reply | Threaded
Open this post in threaded view
|

Re: WSsecurity: SignatureMethod error

Enrique Soriano
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 (??).

>> 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

On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:

> 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
> From: [hidden email]
> To: [hidden email]
>
>
> On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
>>
>> 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
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: WSsecurity: SignatureMethod error

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
> From: [hidden email]
> To: [hidden email]
>
> 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 (??).
>
> >> 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
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 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 they point to the original OASIS spec with this statement:

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

> On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:
> > 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
> > From: [hidden email]
> > To: [hidden email]
> >
> >
> > On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
> >>
> >> 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
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: WSsecurity: SignatureMethod error

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.

On Fri, Mar 11, 2016 at 1:56 PM, Martin Gainty <[hidden email]> 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
> From: [hidden email]
> To: [hidden email]
>
> 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 (??).
>
> >> 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
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 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 they point to the original OASIS spec with this statement:

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

> On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:
> > 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
> > From: [hidden email]
> > To: [hidden email]
> >
> >
> > On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
> >>
> >> 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
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: WSsecurity: SignatureMethod error

Andreas Veithen-2
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

On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <[hidden email]> 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.

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 <[hidden email]> 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
> From: [hidden email]
> To: [hidden email]
>
> 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 (??).
>
> >> 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
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 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 they point to the original OASIS spec with this statement:

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

> On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:
> > 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
> > From: [hidden email]
> > To: [hidden email]
> >
> >
> > On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
> >>
> >> 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
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


Reply | Threaded
Open this post in threaded view
|

RE: WSsecurity: SignatureMethod error

Martin Gainty


On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <[hidden email]> 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/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.

On Fri, Mar 11, 2016 at 1:56 PM, Martin Gainty <[hidden email]> 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
> From: [hidden email]
> To: [hidden email]
>
> 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 (??).
>
> >> 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
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 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 they point to the original OASIS spec with this statement:

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

> On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:
> > 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
> > From: [hidden email]
> > To: [hidden email]
> >
> >
> > On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
> >>
> >> 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
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


Reply | Threaded
Open this post in threaded view
|

Re: WSsecurity: SignatureMethod error

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.





On Sat, Mar 12, 2016 at 2:16 AM, Martin Gainty <[hidden email]> wrote:


On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <[hidden email]> 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/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.

On Fri, Mar 11, 2016 at 1:56 PM, Martin Gainty <[hidden email]> 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
> From: [hidden email]
> To: [hidden email]
>
> 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 (??).
>
> >> 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
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 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 they point to the original OASIS spec with this statement:

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

> On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:
> > 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
> > From: [hidden email]
> > To: [hidden email]
> >
> >
> > On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
> >>
> >> 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
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>



Reply | Threaded
Open this post in threaded view
|

Re: WSsecurity: SignatureMethod error

Andreas Veithen-2
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

On Sat, Mar 12, 2016 at 9:15 AM, Enrique Soriano <[hidden email]> wrote:
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.





On Sat, Mar 12, 2016 at 2:16 AM, Martin Gainty <[hidden email]> wrote:


On Fri, Mar 11, 2016 at 3:55 PM, Enrique Soriano <[hidden email]> 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/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.

On Fri, Mar 11, 2016 at 1:56 PM, Martin Gainty <[hidden email]> 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
> From: [hidden email]
> To: [hidden email]
>
> 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 (??).
>
> >> 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
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 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 they point to the original OASIS spec with this statement:

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

> On Thu, Mar 10, 2016 at 2:31 PM, Martin Gainty <[hidden email]> wrote:
> > 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
> > From: [hidden email]
> > To: [hidden email]
> >
> >
> > On Mar 9, 2016 15:34, "Martin Gainty" <[hidden email]> wrote:
> >>
> >> 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
> >
> > 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>