Hi Nandana,
Thanks again for your quick reply. This appears to be related to the WSDL indeed. In the one I have been given to work with, several schemas coexist. Something like: xmlns:ns1="http://foo.bar" xmlns:ns2="http://foo.bar.foobar" xmlns:tns="MyService" <wsdl:types> <xsd:schema targetNamespace="http://foo.bar"> <xsd:import namespace="http://foo.bar.foobar"> </xsd:import> <xsd:complexType name="myData"> <xsd:sequence> <xsd:element minOccurs="0" name="clinician" nillable="true" type="ns2:CodedElement"/> </xsd:sequence> </xsd:complexType> </xsd:schema> <xsd:schema targetNamespace="http:// foo.bar.foobar "> <xsd:complexType name=" CodedElement "> <xsd:sequence> <xsd:element minOccurs="0" name="ncid" nillable="true" type="xsd:integer"/> <xsd:element minOccurs="0" name="rsFormId" nillable="true" type="xsd:integer"/> <xsd:element minOccurs="0" name="text" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:schema> <xsd:schema targetNamespace="MyService"> <xsd:import namespace="http://foo.bar"> </xsd:import> <xsd:import namespace="http://foo.bar.foobar"> </xsd:import> <xsd:element name="getMyDataById"> <xsd:complexType> <xsd:sequence> <xsd:element maxOccurs="1" minOccurs="1" name="EventId" nillable="true" type="xsd:integer"/> <xsd:element maxOccurs="1" minOccurs="1" name=" myData " nillable="true" type="ns1: myData "/> <xsd:element maxOccurs="1" minOccurs="1" name="ApplicationNcid" nillable="true" type="xsd:integer"/> </xsd:sequence> </xsd:complexType> And so on... I changed the WSDL to use only 1 schema, and it is working fine (even the policy that wouldn't be attached to the stubs). I will create a JIRA and attach the WSDL. Thanks! Best regards, Phil -----Original Message----- From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2008 8:51 PM To: [email protected] Subject: Re: Client not signing in Rampart 1.4 Hi Phil, This is due to a recent improvement in WSS4J which checks for the version of the X509 whenever a SKI referencing mechanism is used. You can make Rampart to use Thumb print references by tweaking the policy a bit. All you need to is add "<sp:RequireThumbprintReference/>" to the X509 assertions. eg. <wsp:Policy> <sp:X509Token sp:IncludeToken=" http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient "> <wsp:Policy> <sp:RequireThumbprintReference/> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> You can look at the complete policy in here [1]. At the same time. Can you create a JIRA [2] in Axis2 with the WSDL you tried so we can check it and debug and fix Axis2 if there is a bug in Axis2. thanks, nandana [1] - http://svn.apache.org/viewvc/webservices/rampart/tags/java/1_4/modules/rampart-samples/policy/sample02/policy.xml?view=markup [2] - On Mon, Oct 13, 2008 at 10:39 PM, Philippe Camus <[EMAIL PROTECTED]>wrote: > Hi Nandana, > > > > > > Thanks for your help! > > > > I checked the populateAxisService() and indeed the policy was not attached > to the stub. After trying different solutions I decided to take the policy > file from your tutorial, and the policy was attached to the stub! Weird > considering that the other policy is working fine with Axis/Rampart 1.2 > (please note that my policy was correctly attached to the binding, not the > port type for the client stub generation). FYI the policy comes from the > book "Developing Web Services with Apache Axis2" from Ka Lok Tong. > > > > Now I am getting another error: > > > > Caused by: org.apache.ws.security.WSSecurityException: An unsupported token > was provided (An X509 certificate with version 3 must be used for SKI. The > presented > cert has version: 1) > > > > This appears to be a known bug (https://wso2.org/jira/browse/WSAS-742), > but I am not sure how to fix this.... > > > > Any idea? Thanks again! > > > > > > Best regards, > > > > Phil > > > > > > -----Original Message----- > From: Nandana Mihindukulasooriya [mailto:[EMAIL PROTECTED] > Sent: Saturday, October 11, 2008 4:59 AM > To: [email protected] > Subject: Re: Client not signing in Rampart 1.4 > > > > Hi Phil, > > Please try using > > > > > sc.getAxisService().getPolicySubject().attachPolicy(getRampartConfiguration()); > > > > instead of the policy include. You can check the populateAxisService() > > method of the generated stub to check whether policies are correctly > > attached. Please use Axis2 1.4.1 instead of Axis2 1.4. Please take a > > look at "Security Vulnerabilities in Apache Axis2 1.4 / Rampart 1.4 > > and Avoiding Them" [1]. > > > > thanks, > > nandana > > > > [1] - http://wso2.org/library/3787 > > > > On 10/11/08, Philippe Camus <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > I am using Rampart 1.4 and Axis2 1.4, and trying to sign my messages. I > had > > > a piece of code working fine in Axis/Rampart 1.2, and I am trying to port > it > > > 1.4. > > > > > > For some reason my client won't encrypt its messages and I cannot figure > out > > > why..... so everything is working in clear text (I haven't configured the > > > server side yet, and simply wanted to see the signed request in TcpMon). > > > > > > ConfigurationContext context = > > > > ConfigurationContextFactory.createConfigurationContextFromFileSystem("repository", > > > null); > > > ServiceStub service = new ServiceStub(context, > > > "http://localhost:1256/axis2/services/Service?wsdl"); > > > ServiceClient sc = service._getServiceClient(); > > > sc.engageModule("rampart"); > > > StAXOMBuilder builder = new StAXOMBuilder("rampart-config.xml"); > > > Policy rampartConfig = > PolicyEngine.getPolicy(builder.getDocumentElement()); > > > > sc.getAxisService().getPolicyInclude().addPolicyElement(PolicyInclude.AXIS_SERVICE_POLICY, > > > rampartConfig); > > > > > > FYI, the client is generated from the WSDL containing the encryption > policy > > > using the "wsdl2code" ANT task. > > > > > > How can I debug the client side to see if the policy is correctly picked > up? > > > Thanks! > > > > > > Best regards, > > > > > > Phil > > > > > > >
