I need to implement a WCF service that conforms to the specs set forth by Phase II CORE 270 Connectivity Rule.
I generated the service using svcutil.exe and the supplied wsdl.
Given that we had chosen to handle security through username/password over SSL and the requirement for SOAP 1.2 addressing, I configured the service as a
customBinding:
<customBinding>
<binding name="ServiceBinding">
<security
authenticationMode="UserNameOverTransport"
messageSecurityVersion="WSSecurity11WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
</security>
<textMessageEncoding messageVersion="Soap12" />
<httpsTransport />
</binding>
</customBinding>
The WSDL produced matches that of the WSDL provided by the spec. Using a supplied soap message:
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="true">
<wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-21621663">
<wsse:Username>bob</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-usernametoken-profile-1.0#PasswordText">bobPW</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<ns1:COREEnvelopeRealTimeRequest
xmlns:ns1="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd">
<PayloadType> X12_270_Request_005010X279A1004010X092A1</PayloadType>
<ProcessingMode>RealTime</ProcessingMode>
<PayloadID>f81d4fae-7dec-11d0-a765-00a0c91e6bf6</PayloadID>
<TimeStamp>2007-08-30T10:20:34Z</TimeStamp>
<SenderID>HospitalA</SenderID>
<ReceiverID>PayerB</ReceiverID>
<CORERuleVersion>2.2.0</CORERuleVersion>
<Payload><![CDATA[ISA*00* *00* *ZZ*NEHEN780 *ZZ*NEHEN003 ...IEA*1*000000031]]></Payload>
</ns1:COREEnvelopeRealTimeRequest>
</soapenv:Body>
</soapenv:Envelope>
and SoapUI, I am receiving a
System.ServiceModel.Security.MessageSecurityException, System.ServiceModel,
Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. This can occur if the service is configured for security and the client is not using security.
It would seem that the service does not understand the wsse namespace prefix as if I flip the namespace prefix to o the service does not have an issue with the request.
EDIT
I cannot seem to find the mismatch in the binding or an issue with their message indicating I am chasing up the wrong tree. Any other potential leads would be helpful. Is there a way to make a custom binding with SOAP 1.2 addressing inter-operable with the provided SOAP message?
I have a WCF service that has the following requirements:
Sent over SSL (HTTPS Transport)
Reliable Messaging On
WS-* message security using a X.509 certificate.
Replay Detection On
Here is the binding that I have:
<customBinding>
<binding name="replayDetectionBinding">
<reliableSession />
<security authenticationMode="SecureConversation">
<secureConversationBootstrap authenticationMode="CertificateOverTransport"
protectTokens="true">
<issuedTokenParameters keyType="AsymmetricKey" />
</secureConversationBootstrap>
<localServiceSettings maxClockSkew="00:01:00"
replayWindow="00:01:00" />
</security>
<textMessageEncoding />
<httpsTransport maxReceivedMessageSize="5242880" maxBufferSize="5242880" />
</binding>
</customBinding>
The service is hosted in IIS and I have a test client to make a request to the service. I have Fiddler up and running to catch all messages coming to and from the test client and the WCF service.
Everything is working, including the replay detection outside of the replay window. However, what I need is to have the replay detection use the nonce cache so that an identical message is rejected no matter what (as long as that message signature is in the nonce cache). This part is not happening.
I send a message using the test client, it is received by the WCF service and a response is returned, I do not close the connection. I then use Fiddler to reissue/replay the message that was sent. In this case, it is accepted by fiddler - even if I issue it from another machine.
I've done so much searching and have read just about everything I can find, but cannot get this to work.
Does anyone know how to enable the nonce cache in this case or do you have to code your own?
I created a WCF service which uses MSMQ.
Multiple .NET clients should be able to consume this service and send messages to it.
Partially the clients are written in .NET versions where there was no WCF (e.g. .NET 1.1).
For these clients I make direct use of the Msmq API.
The problem is, that the encoding of the messages don't fit the expected encoding on the service-side.
So I tried to alter the message encoding on the service-side using a customBinding:
<bindings>
<customBinding>
<binding name="MyCustomBinding">
<!-- available encodings: -->
<!-- <textMessageEncoding /> -->
<!-- <binaryMessageEncoding /> -->
<!-- <mtomMessageEncoding /> -->
<!-- <webMessageEncoding /> -->
<msmqTransport ...>
<msmqTransportSecurity ... />
</msmqTransport>
</binding>
</customBinding>
</bindings>
I guess I am restricted to one of the four pre-defined encodings: textMessageEncoding, binaryMessageEncoding, mtomMessageEncoding, webMessageEncoding.
On the client side I tried to alter the formatter:
System.Messaging.Message msmqMessage = new System.Messaging.Message();
msmqMessage.Formatter = new System.Messaging.ActiveXMessageFormatter();
//msmqMessage.Formatter = new System.Messaging.BinaryMessageFormatter();
//msmqMessage.Formatter = new System.Messaging.XMLMessageFormatter();
It seems that no formatter fits to an expected encoding.
Is there another way of unifying the encoding?
Perhaps a custom encoder or something like that?
Or am I completely wrong with adjusting formatter and encoder?
Thanks in advance.
You can use the built in MsmqIntegrationBinding and set the serialization format to xml:
<service name="MyQueueListenner">
<endpoint address="msmq.formatname:DIRECT=OS:.\private$\myQueue"
binding="msmqIntegrationBinding"
bindingConfiguration="DotNetBinding"
contract="MyContract" />
</service>
...
<msmqIntegrationBinding>
<binding serializationFormat="Xml" name="DotNetBinding" durable="false" exactlyOnce="false">
<security mode="None" />
</binding>
</msmqIntegrationBinding>
UPDATE
The whole point of integration binding is maximum interoperability so that wcf can support non-.Net msmq clients (ActiveX, Java).
For this reason exposing data contracts (beyond String) would not be meaningful.
I guess MS didn't really imagine people would use it for interop between lower .Net versions and WCF.
The only thing I can suggest is host a mex endpoint defining a set of one-way operations exposing your types over http and then allow clients to consume the wsdl from this endpoint.
They can then use this to build up their local type definitions for use with your msmq endpoint.
Just make it clear they should not actually call the http operations, or have the operations throw a NotImplementedException.
Yes, I've read the other questions on SO, MSDN, and other sites, but I found no answers as clear as I can understand. I need to set my Silverlight application's WCF references relative to the site that it's loaded from, but I can't get it to work. There is no problem with the service itself, it is working. When I move from local to my real server, I get errors in my SL app complaining about not connecting to localhost.
Here is my ServiceReferences.ClientConfig file:
<configuration>
<system.serviceModel>
<bindings>
<customBinding>
<binding name="CustomBinding_AccountManager">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="CustomBinding_FileManager">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
<binding name="CustomBinding_SiteManager">
<binaryMessageEncoding />
<httpTransport maxReceivedMessageSize="2147483647" maxBufferSize="2147483647" />
</binding>
</customBinding>
</bindings>
<client>
<endpoint address="http://localhost:60322/AccountManager.svc"
binding="customBinding" bindingConfiguration="CustomBinding_AccountManager"
contract="AccountManager.AccountManager" name="CustomBinding_AccountManager" />
<endpoint address="http://localhost:60322/FileManager.svc" binding="customBinding"
bindingConfiguration="CustomBinding_FileManager" contract="FileManager.FileManager"
name="CustomBinding_FileManager" />
<endpoint address="http://localhost:60322/SiteManager.svc" binding="customBinding"
bindingConfiguration="CustomBinding_SiteManager" contract="SiteManager.SiteManager"
name="CustomBinding_SiteManager" />
</client>
</system.serviceModel>
</configuration>
Yes, I will optimize the buffer/message sizes and I know the possible DoS exploits, forget about it for now, I need them for big file transfers. An approach I tried is while instantiating the clients, I've used this code:
fileManager = new FileManagerClient(new BasicHttpBinding(), new EndpointAddress("http://" + Settings.Host + "/FileManager.svc"));
accManager = new AccountManagerClient(new BasicHttpBinding(), new EndpointAddress("http://" + Settings.Host + "/AccountManager.svc"));
where Settings.Host is my own method which returns me the host that the SL app is running from, tested, works. When I uploaded my XAP and tried, it still wanted to go for http://localhost:60322/AccountManager.svc, after further investigation, I've realized that there are still lots of references to localhost, in unseen files:
AccountManager.disco:
<?xml version="1.0" encoding="utf-8"?>
<discovery xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/disco/">
<contractRef ref="http://localhost:60322/AccountManager.svc?wsdl" docRef="http://localhost:60322/AccountManager.svc" xmlns="http://schemas.xmlsoap.org/disco/scl/" />
</discovery>
Parts of AccountManager.wsdl:
... <wsdl:import namespace="" location="http://localhost:60322/AccountManager.svc?wsdl=wsdl0" />...
...[lots of operation declarations]...
<wsdl:service name="AccountManager">
<wsdl:port name="CustomBinding_AccountManager" binding="tns:CustomBinding_AccountManager">
<soap12:address location="http://localhost:60322/AccountManager.svc" />
<wsa10:EndpointReference>
<wsa10:Address>http://localhost:60322/AccountManager.svc</wsa10:Address>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
Part of AccountManager1.xsd:
<xs:import schemaLocation="http://localhost:60322/AccountManager.svc?xsd=xsd2" namespace="http://schemas.datacontract.org/2004/07/Leftouch.Data.Summary" />
Part of configuration.svcinfo:
<endpoint normalizedDigest="<?xml version="1.0" encoding="utf-16"?><Data address="http://localhost:60322/AccountManager.svc" binding="customBinding" bindingConfiguration="CustomBinding_AccountManager" contract="AccountManager.AccountManager" name="CustomBinding_AccountManager" />" digest="<?xml version="1.0" encoding="utf-16"?><Data address="http://localhost:60322/AccountManager.svc" binding="customBinding" bindingConfiguration="CustomBinding_AccountManager" contract="AccountManager.AccountManager" name="CustomBinding_AccountManager" />" contractName="AccountManager.AccountManager" name="CustomBinding_AccountManager" />
Part of Reference.svcmap:
</ClientOptions>
<MetadataSources>
<MetadataSource Address="http://localhost:60322/AccountManager.svc" Protocol="http" SourceId="1" />
</MetadataSources>
<Metadata>
<MetadataFile FileName="AccountManager2.xsd" MetadataType="Schema" ID="e473b2d5-7af3-4390-87c3-a4fc3f54fb96" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?xsd=xsd2" />
<MetadataFile FileName="AccountManager1.xsd" MetadataType="Schema" ID="fd3a1ae0-b38b-4586-8622-5b0ee07e39fb" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?xsd=xsd0" />
<MetadataFile FileName="AccountManager.xsd" MetadataType="Schema" ID="6a49ee64-6eac-40e2-bcff-26418435e777" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?xsd=xsd1" />
<MetadataFile FileName="AccountManager.disco" MetadataType="Disco" ID="9ec9a8cc-0cf0-4264-a526-b5a6c08f7d36" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?disco" />
<MetadataFile FileName="AccountManager1.wsdl" MetadataType="Wsdl" ID="54a5b2c0-9d0e-4043-a7e4-d27ae6674bfc" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?wsdl=wsdl0" />
<MetadataFile FileName="AccountManager.wsdl" MetadataType="Wsdl" ID="f8923013-3a6c-412b-b7da-bee5a5a7bb64" SourceId="1" SourceUrl="http://localhost:60322/AccountManager.svc?wsdl" />
..and ALL these again for other 2 services too.
I am not a master of web services/bindings/endpoints/operation contracts or any related stuff. I just want to make my totally already-nice-working (when URI is hardcoded) system work for relative URIs, that's all I need. There must be a simple solution. Can someone explain what exactly those file types and declarations resemble, which are important and which are optional, and how can I create dynamic service references in the cleanest form. Please, with explanations. I've already seen lots of posts and articles about dynamic service bindings and references, but honestly, everything gets messed up and I end up not understanding anything from it. Any constructive criticism and solutions are welcome.
Is the config file for your service (not the client) using endpoints with fully qualified addresses (like your client config)? If so, the reason you're seeing all those localhost references is because when you add the service reference, it's going to carry through that address in the generated files.
Update the endpoint in your service config file to either use the fully qualified address on that machine (i.e., http://somname.com/service.svc), or set the baseAddresses in the config file to the machine name.
Additionally, if you're using WCF 4.0 (VS 2010/.NET 4.0), you can have WCF create a default endpoint for your service(s) by ommitting the endpoints from the config file altogether (as I understand it - we're just moving to 4.0 at work now, so I haven't played with the new features).
EDITED TO ADD
New approach, same basic idea (that the URI is being imported from somewhere). Based on your comments below, it sounds like your service's config is set up fine, with no hard-coded URIs pointing to localhost.
When you move your application to the target server(s), are you updating your reference to your service (via the Add Service Reference) as well, or simply moving the files that generates from your local box to the target server?
If you are, I'm wondering if that might be the source of your problem. I would think that specifying the service address when you create the client should override anything in the WSDL-related files, but maybe its not.
Something to try:
Delete the <client> section from your Web.config. Then, when you create the client, do so like this:
fileManager = new FileManagerClient(new BasicHttpBinding("CustomBinding_FileManager"), new EndpointAddress("http://" + Settings.Host + "/FileManager.svc"));
Make sure you pass in the name of the binding configuration section in the BasicHttpBinding constructor, otherwise you'll get the binding with the default values, not the larger values you specified.
The idea here is to eliminate any chance that the client config file settings are overriding what you're passing in on the FileManagerClient creation.
I'd consider it less than ideal to have to update the service reference for every deployment to each individual server - what you're trying to accomplish makes sense. I do something similar in an n-tier app I've written - the only difference is that I don't use service references, I generate the proxy via SvcUtil and then generate channels via ChannelFactory<T>, which is another route you might want to look at.
If none of this help, please feel free to e-mail me (my e-mail address is in my profile) - it might be easier to figure this out via e-mail exchange and then post the final solution.
I am trying to use a WCF client to call a third party web service.
The web Service usses username token authentication WSS-Security 1.0 Soap Message Security
Here is a sample soap authentication header for what the web service expects
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Header>
<wsse:Security soap:mustUnderstand="1">
<wsse:UsernameToken namespaces>
<wsse:Username>username</wsse:Username>
<wsse:Password Type="type info">password</wsse:Password>
<wsse:Nonce>nonce</wsse:Nonce>
<wsu:Created>date created</wsu:Created>
</wsse:UsernameToken>
<wsse:Security>
</soap:Header>
<soap:Body>
<WebServiceMethodName xmlns="Web Service Namespace" />
I configured the client to the following way
<basicHttpBinding>
<binding name="Binding1">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Basic"/>
</security>
</basicHttpBinding>
but recieved an error that stating that the nonce and datecreated attributes were missing in the header. Does anyone know how to configure a WCF client to work with
WSS-Security 1.0 Soap Message Security username token authentication?
I had the same problem. Instead of the custom token serlializer I used a MessageInspector to add the correct UsernameToken in the BeforeSendRequest method. I then used a custom behavior to apply the fix.
The entire process is documented (with a demo project) in my blog post Supporting the WS-I Basic Profile Password Digest in a WCF client proxy. Alternatively, you can just read the PDF.
If you want to follow my progress through to the solution, you'll find it on StackOverflow titled, "Error in WCF client consuming Axis 2 web service with WS-Security UsernameToken PasswordDigest authentication scheme":
Been looking at the same problem and my findings are that unfortunately WCF doesn't support Nonce values.
If you want to send username and password (timestamp is included by default) change the config to
<basicHttpBinding>
<binding name="BasicHTTP">
<!-- UsernameToken over Transport Security -->
<security mode="TransportWithMessageCredential">
<message clientCredentialType ="UserName" />
</security>
</binding>
</basicHttpBinding>
Also be aware that it appears to be a defect (at least different interpretation of the standards) with regards to the UserNameToken when exchanged between WCF and WSS4J see http://social.msdn.microsoft.com/Forums/en/wcf/thread/6bc1b0e4-424b-4e2a-909c-815095be631f
WSSConfig.getDefaultWSConfig().setAllowNamespaceQualifiedPasswordTypes(true); might be a workaround on the WSS4J side.
UPDATE: On the WCF side you can get around the problem by implementing a CustomCredential and CustomTokenSerializer ref last post at
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/4df3354f-0627-42d9-b5fb-6e880b60f8ee
Dagfinn