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 > From: enrique.sori...@gmail.com > To: java-user@axis.apache.org > > 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 <mgai...@hotmail.com> wrote: > > > > > > > > > > > >> Date: Tue, 8 Mar 2016 14:40:27 +0100 > >> Subject: WSsecurity: SignatureMethod error > >> From: enrique.sori...@gmail.com > >> To: java-user@axis.apache.org > >> > >> 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: java-user-unsubscr...@axis.apache.org > >> For additional commands, e-mail: java-user-h...@axis.apache.org > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org >
