ws-security

I'm successful in communicating with a WCF service via SoapUI (I was given specification on how to configure it), but I'm having trouble in copying those settings to .NET application. Turns out the shape of generated SOAP message (peeked via Fiddler) is being rejected by the web service, who expects a stricter layout of envelope. I'm very close. On this picture... ... you can see three SOAP messages: 1. With X509SecurityTokenParameters.InclusionMode set to AlwaysToRecipient 2. With X509SecurityTokenParameters.InclusionMode set to Never 3. Expected security token, tested on SoapUI. How do I

I need to integrate with a legacy .NET Web Service that uses WSE 2.0 for WS-Security and DIME. The catch is I need to do this from a Java application. I'm expecting that Axis2 works fine with the WS-Security because folks around here have done it before. It's the DIME that I'm concerned about. I see a reference to DIME at http://ws.apache.org/axis/java/client-side-axis.html , but I'm wondering if anyone has actually done this with Axis and a WSE 2.0 Web Service. I can't tell you anything for sure from own expierence. And about every 2nd page on the "web" seems to state something different to

I have a custom binding like following for my WCF service which I am trying to call from the soapUI 4.5.1 <customBinding> <binding name="NewBinding0"> <transactionFlow /> <security authenticationMode="MutualCertificate" defaultAlgorithmSuite="Basic128" securityHeaderLayout="Lax" includeTimestamp="false" messageProtectionOrder="SignBeforeEncrypt" allowInsecureTransport="true" requireSignatureConfirmation="false" requireDerivedKeys="false" keyEntropyMode="ClientEntropy" requireSecurityContextCancellation="false" allowSerializedSigningTokenOnReply="true" messageSecurityVersion=

I am building a WCF web service with a customBinding endpoint and am getting stuck accepting the WS-Security header that is being sent to me by another party. We are both following a specification authored by the UK National Health Service, so I am unable to amend the requirements. The basic structure of the <wsse:Security> header should be as follows, according to the specification: <wsse:Security> <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurityutility-1.0.xsd" wsu:Id="6CCF6A2B-11A6-11DF-86D1-236A99759561" > <wsu:Created>2012-06-12T09:00:00Z</wsu

I have a web service which implements WS-Security but does not define a policy in the WSDL. I am able to consume this web service successfully using Axis 2 as client. I am trying to consume the same web service using Metro 2 but the wsse:security headers are not going. It works only if the service defines the security policy which is not under my control. I tested this by creating a sample web service and unless I define the policy my metro client never sends the wsse:security headers. Is there anything I am missing using Metro? EDIT-------------------------------------------------------------

We are implementing WS-Security Policy on our web services with the following framework/module/specification. Apache Axis2 1.6.2 Apache Rampart 1.6.2 WS-Security Policy 1.2(namespace: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 ) We are facing the following issues while creating/consuming the service. Axis2 wsdl generation logic ignores <sp:NoPassword/> assertion. After debugging,I realized that it is because of the logic in org.apache.ws.secpolicy.model.UsernameToken (rampart-policy-1.6.2.jar) that expects <sp:WssUsernameToken11 /> ( or <sp:WssUsernameToken10 /> ) to be

I am using WCF Message level security with the following wsHttpBinding <security mode="Message"> <message clientCredentialType="Windows" establishSecurityContext="false" /> </security> Each time i call the service is a separate operation, and there is no need to keep any session state. I am running into a problem with load balancer, because WCF keeps re-using security tokens, so if the first call goes to NodeA, it creates a security token which is re-used. If that token is passed to NodeB tripping up MessageSecurityException Seems like microsofts answer to this is to use sticky sessions, which