My WFC service uses wsHttpBinding configured with:
<security mode="TransportWithMessageCredential">
<message establishSecurityContext="True" clientCredentialType="UserName"/>
<transport clientCredentialType="None" proxyCredentialType="None"/>
</security>
One of our partner is trying to invoke our services using the java the Metro library. They have this problem. I have to set establishSecurityContext="False" for this to work. We did a quick test and it works indeed when I set it to false.
What would be the impacts of not using secure sessions (by setting establishSecurityContext="False"). I'm already running on https. So will I be OK in terms of security? And are there other impacts to consider (performance maybe)?
Thanks
The difference is that the on an non-SCT (security context token) enabled endpoint, key exchange and validation must be done per call as opposed to being done once and cached for the session and only a SCT passed around in the messages instead. SCTs are based on a symmetric key which makes them much more efficient for signing/encrypting the message. The use of a SCT is very good when the client is expected to make many calls in succession because it alleviates the need to do the exchange and validation of a one off key every time.
What I would recommend is that you just expose another endpoint for clients that don't support SCTs and tell them to use that. Clients that can use SCTs you keep pointed at the default endpoint and keep all the benefits that come with it.
For more on the subject, check out section three of the WS-SecureConversation documentation.
Related
I host a WCF Service on IIS and have the following binding in web.config:
<bindings>
<wsHttpBinding>
<binding name="transactionalBinding"
transactionFlow = "true"
sendTimeout = "00:00:01"
receiveTimeout = "00:00:01"
openTimeout = "00:00:01"
closeTimeout = "00:00:01">
<security mode="Transport">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
</security>
</binding>
</wsHttpBinding>
</bindings>
In my service method I sleep for 10 seconds. I do not get a timeout exception when calling my service method from a client.
Is there any meaning in defining timeouts in server side bindings?
I do not get a timeout exception when calling my service method from a client.
TL;DR: because WCF timeouts by default are one minute so naturally a server operation that only takes 10 seconds isn't going to timeout. The timeouts you have specified on the server would only affect transmission not execution of your method. (you aren't calling anything else)
You are specifying the timeouts in the server config. What you need to do is specify the timeouts in the client's config file, specifically SendTimeout. Essentially whatever end is making the call, needs to specify the operation timeout. Probably not relevant in your case but if your "server" in turn made another WCF call to another service, you would want your own timeout there too.
MSDN:
SendTimeout – used to initialize the OperationTimeout, which governs the whole process of sending a message, including receiving a reply message for a request/reply service operation. This timeout also applies when sending reply messages from a callback contract method.
Generally, WCF client and server configs should match one another and unless you are using Add Service Reference/Refresh Service Reference each time the server contracts and/or config change, the client won't know about it. By the way, avoid the latter because it duplicates your model and can lead to runtime errors if they are out of sync. Not to mention service contracts can get out of sync.
A passing thought
And this brings up one of the problems of WCF configuration via config files, they are subject to runtime errors impossible to find at compile time.
A better practice is to do away with config files completely and do programatic configuration via a common assembly that both your client and server use. Specify bindings in code along with your timeouts.
That way both server and client are always in sync with regards to WCF configuration.
With both client and server agreeing on timeouts would have addressed some issues.
Tell me more
WCF the Manual Way… the Right Way
I have a WCF service in my application.
When the amount of data that passes from server to client is small I do not have problems.
The problems come when there's a big amount of data.
The proxy method runs a stored procedure that retrives data in an acceptable time.
The method server side return correctly,
BUT it takes more that two minutes to return properly to the client and continue the execution client side.
During this period if I stop the application it seems that no actions are in execution.
I don't know if it's an IIS problem or a configuration of the net.tcp binding.
The only thing I'm able to do is to execute the proxy in an external application and it that case I no have problems.
EDIT***
This is the binding configuration:
<binding name="NetTcpBinding_INService" closeTimeout="24.00:00:00" maxReceivedMessageSize="2147483647"
openTimeout="24.00:00:00" receiveTimeout="24.00:00:00" sendTimeout="24.00:00:00">
<security mode="None" />
</binding>
I host a public service (so I can't control client PC clocks). I'm using
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
The max time difference allowed (MaxClockSkew) is 5 minutes.
What is the definitive way to disable this functionality and / or make it really large like 2 days?
The only safe, simple way I can think of is to just use transport credentials under https and pass the username and password to every method call. Surely I don't have to resort to this?
I've looked at https://msdn.microsoft.com/en-us/library/aa738468.aspx and I don't fully understand it - i.e. where to apply in my world. I just use add service reference and the default proxies at present. Can it be defaulted in the server so that adding/updating a client reference picks it up?
I've a WCF service that only about 15-20 clients are calling once every three minutes. I have PerfMon hooked up to it, and it's showing that I have 2147483698 Instances. That can't be, can it? I have maxConcurrentInstances="1000" in the web.config and I'm using Multiple and PerSession Concurrency and InstanceMode respectively.
This WCF service is also causing some other problems like making lsass.exe use all the available CPU.
Edit More Info
It is hosted in IIS 6 and is using an endpoint with WsHttpBinding:
<wsHttpBinding>
<binding name="WSHttpBinding_IWCFService"
maxBufferPoolSize="524288" maxReceivedMessageSize="1048576">
<readerQuotas maxDepth="32" maxStringContentLength="65536" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="Message">
<message clientCredentialType="Certificate" negotiateServiceCredential="true"
algorithmSuite="Default" />
</security>
</binding>
</wsHttpBinding>
I have the Concurrency set to Multiple to because I want the Service Objects that are created to be able to handle more than one request at a time (ie multiple threads). I suppose I could make the InstanceMode Single, instead of PerSession, but would that make a difference here?
Edit Next Morning
So, I got on this morning and opened PerfMon, everything was flatlined at 0. I removed then created the the service in IIS, and also restarted the service by modifying the config. I then watched the Instances climb up to 1000 (the max in my config), at which point no more calls were coming in. I restarted the service again using the config, the number of Instances immediately dropped to 0, then 5 seconds later shot up to 2 billion again.
I feel like part of this might just be that Perfmon doesn't know how to handle whatever madness is being thrown at it from the WCF service.
The problem does seem to be that the channel is not always being closed properly in this particular version of the client and unfortunately, I can't get to them all at the moment. (I have another version of the client and service that has about 130 clients and this isn't a problem.) Is there some configuration I could set the service up as to help the problem? From what I've read, Single InstanceMode and Multiple Concurrency would be appropriate. It would solve the Instance problem and still give me asynchronous access, and I don't have to worry about cross threading issues because the service methods only update tables in a DB.
Thoughts?
It sounds like the instances are not being disposed of correctly.
As a test you could append the following line of code to the implementation (in the service) of the method(s) being called by the clients, and see if the number of instances reduces:
OperationContext.Current.InstanceContext.
ReleaseServiceInstance();
You could also try switching to per-call and get rid of the concurrency stuff (I can't tell from your question if that option would be suitable for what you are doing)? Per call will create a separate instance for every method call that a client makes, and dispose of the instance afterwards.
There is a nice article that goes into all the details of instance management here, hopefully you will find something helpful there :)
I'm trying to get IIS6 to work reliably with a WCF service I have hosted in a separate Windows Service application on the same machine. Users connect to IIS via some HTTP exposed services, which is working fine, and then IIS needs to get some information from the Windows service to put in the HTTP response. I also need a callback channel between the Windows Service and IIS.
After a lot of effort I got it working with a netTcpBinding and everything would be rosey for 5 or 10 minutes but after that IIS would report the WCF channel as being faulted and then clam up and stop processing any requests until the worker process got recycled and the whole thing repeated.
I've been trying to swap to a netNamedPipeBinding but IIS refuses or is refused access to the pipe with an "There was no endpoint listening at net.pipe://localhost/mypipename" error. I can connect to the pipe fine from a console app.
So my question is has anyone got either of those two bindings working with IIS as a client or have any other approaches?
We are using IIS 7 hosting about 20 services with the net.tcp and net.pipe bindings and it's working fine.
Your problem with the pipe looks like a misconfiguration to me. If it helps, this is how we have them configured:
Server:
<endpoint address ="" binding="fooBinding"
contract="Bla.IBlaAPI"
bindingConfiguration="BlaAPI.BindingConfig">
Binding config:
<binding name="BlaAPI.BindingConfig"
receiveTimeout = "10:50:00"
sendTimeout = "10:50:00"
maxReceivedMessageSize="2147483647"
maxBufferSize="2147483647"
maxBufferPoolSize="2147483647"
transactionFlow="false">
<readerQuotas maxDepth="32"
maxStringContentLength="2147483647"
maxArrayLength="2147483647"
maxBytesPerRead="8192"
maxNameTableCharCount="2147483647" />
<security mode="None"/>
</binding>
Note that we are using long timeouts and have really high quotas for message size and etc. because we are passing some big chunks of data through this service. You can adjust for your own needs. We have the security set to "none" because the service is only being contacted from the local machine which is secured. Again, your mileage may vary.
Client:
<endpoint name="Bla.Bindings.BlaAPI" address="net.pipe://localhost/bla/IBlaAPI.svc"
behaviorConfiguration="BlaAPI.ServiceBehavior"
binding="netNamedPipeBinding" bindingConfiguration="BlaAPI.BindingConfig"
contract="Bla.IBlaAPI" />
About the Faulted state problem, please note that if an unhandled exception occurs during execution of the service code, the service instance will remain in Faulted state until it is closed properly. To avoid this, either handle exceptions at service top-level or use, for example, Enterprise Library Excexption Handling blocks.
Re NetNamedPipeBinding and "There was no endpoint listening at net.pipe://localhost/mypipename"
Is your web application impersonating its users? The above error is what you get if you try to access a WCF service via the named pipe binding, in a security context whose logon token has membership of NETWORK USERS. The WCF client-side channel stack doesn't distinguish between access denied errors and "not found" errors, when it attempts to read the shared memory object created by the service to publish the name of the pipe in use. (See http://blogs.charteris.com/blogs/chrisdi/archive/2008/05.aspx etc)
Impersonation tokens in an IIS application will always have NETWORK USERS membership.
Can you show me the code you use to dispose of the wcf client proxy?
Never use 'using' on a wcf proxy, as it will not dispose correctly every time. This can possibly lead to the faulted state.