I have read numerous posts and articles about the element in client endpoints on a WCF client but I am still a little confused. I have a client which gets SSPI errors when attempting to communicate with a net tcp WCF service. However, when I add the following into the configuration it works fine
<identity>
<servicePrincipalName />
</identity>
Now from what I have read this is telling the service to use NTLM rather than Kerberos. However, I am still not getting it.
Does anyone have a few moments to explain this simply for me please. So, what is going on here, a little bit of background on the difference of NTLM and Kerberos, why it would work with one and not the other, why this element doesn't need a value, how to configure a service not to need it and why it is needed at all?
Thanks
Here is a blog post explaining ntlm versus kerberos with respect to WCF:
http://blogs.msdn.com/ashishme/archive/2006/11/10/ntlm-vs-kerberos-windows-communication-foundation.aspx
Related
I have started the WCF security token service template in Visual Studio. I get all things up and running over http. So now I have an STS, a WCF Service and I can call GetData(int) with the WCFTestClient. This is running on http.
Now I want to run the STS on https. So I've added it to IIS and added an https endpoint. If I browse to the sts it works on https now.
Next I create a WCF Service, add an sts reference etc. I add this WCF Service to IIS too, on https.
And the last step I create a console app, but then when I call the WCF service Cardspace is started and I get an error. First problem: I don't want Cardspace to start, and it shouldn't start as far as I know. Second: the error message is 'incoming policy failed validation'.
What are the steps to run the STS on https? Is there a tutorial?
Does anyone else finds this a familiar situation, and knows a solution?
I had the problem of cardspace starting myself and after checking the wif configuration several times I found some error in the config. After fixing the config error, everything worked.
Sorry that I could be more spesific one the error (too long ago). But be very, very sure that you have configured your sts and wcf correctly.
Did you try specifying the following: in your config under message.
<issuer address="stsurl" binding="ws2007HttpBinding"
bindingConfiguration="stsbindingconfig">
<identity>
<userPrincipalName value="fqnofUpn" />
</identity>
</issuer>
I'm currently designing and developing a WCF 4 RESTful service that will be used by mobile devices. I specifically picked REST because it's supposedly lightweight and the JSON output makes parsing simple for the mobile clients.
The service takes care of the mobile devices part of the entire application. But, it requires that users log in before using the service. Basic HTTP authentication is not an option: It's insecure and a man-in-the-middle attack could easily intercept the user accounts. SSL is an option here, but I have no idea how easily SSL works on a WCF RESTful service and how simple it is to implement on mobile devices.
I've looked into Digest Authentication, but I can't really find any good information on how to implement it. And that also brings up: How am I going to allow users to add a device to their account with this? Hash the username/password combination into the Digest header along with other information?
Could someone shed some light on this? Because I'm confused as hell. There is plenty of information on the net on how to implement WCF (RESTful) services, but the moment you need to secure it, the amount of information drops significantly... Articles are welcome.
Leveraging SSL is brain dead simple in WCF and should be supported by every mobile platform at this point. You should defintiely go basic auth with SSL to keep your life as simple as possible IMHO.
All you need to do to enable HTTPS on your WCF service is:
<webHttpBinding>
<binding name="MyBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic" />
</security>
</binding>
</webHttpBinding>
That will say "only allow access to this service over a secure transport and expect a basic auth credential to be passed".
Now, the only question is, where are you hosting your WCF service? If hosting in IIS you need simply need to configure the service certificate with it and you're all set.
Another option is to do SSL up front with an F5 device or something like that. Then you have to do a little more work because, by default, WCF will not let you pass crendentials over a non-secured transport. Then you need to get into customizing your own binding and setting the AllowInsecureTransport = true on the TransportSecurityBindingElement. This will basically say "trust me, I'm doing the right thing" to WCF and allow the service to initialize propertly even though the credential will flow over a non-secure binding.
I have converted my webservice to wcf service keeping the extension of wcf service as asmx since I have a large client base and do not want to ask users to change the extension. Currently I have username / pwd authentication for my clients which I want them to move out of. Since my user base calls my web service from all sorts of machines and OS's, I am not able to get what type of authentication I can move them to.
X509 Certificate, issued tokens, username pwd or something else..? Any help or guidance with some sample code blocks or urls' would be appreciated.
If you are replacing ASMX service with WCF service you are using BasicHttpBinding (and perhaps also AspNetCompatibility). In that case you don't have many choices. You can use Transport security (HTTPS) with client certificates or TransportWithMessageSecurity (HTTPS + UserName token profile). If you don't want to use HTTPS and you still want to use UserName token profile you need .NET 4.0 and you have to create custom binding like:
<customBinding>
<binding name="InsecureCredentials">
<security mode="UserNameOverTransport" allowInsecureTransport="true" />
<textMessageEncoding messageVersion="Soap11" />
<httpTransport />
</binding>
</customBinding>
Ultimately, it depends on whose doing the calling for to your service, IMO.
If this is primarily B-to-B, meaning that your clients are some automated process rather than, say, a silverlight app, I'd prefer identity certs (i.e. x509). If this is a user-driven call such as a silverlight app, then I'd stick with username/password, but consider federated identity.
That said, given the fact that you have many different types of clients, even if it's b-to-b there's no guarantee you'll be able to service every client with x509. In my experience, too many shops just aren't flexible enough to adopt "newer" standards (even though x509 has been around a long time, it's still "new" to a lot of people making web service calls). Therefore, it might be best for you to stick with username/password.
You could offer all three, however. WCF is very very nice that way; it's quite simple to set up a single service implementation that just happens support either username/password auth or x509 or federated identity. Almost all of that is handled by the binding configuration; you might need some plugin code for the username/password auth (depending on how you're set up) but the auth code is completely divorced from the service code.
We host a WCF webservice on Windows Server 2003. This server only has 2 internal IP's. We want to expose the service externally. This is done through the firewall that maps an external IP to the service.
So, I would need to modify the service to display that external IP for the internal links. This is not an issue since it should only be used externally.
Changing the Host Header value in IIS gives a 'Bad Request (Invalid Hostname)' response from IIS. I also added an 'address' value to the endpoint entry in the web.config ... but it sill just points to the internal machine name. Any ideas?
edit: I can verify that IIS7 has the exact same behaviour. Address didn't work. Different hostname gave Invalid Hostname error. Is there seriously no way to present a different (fictive) IP? :/
edit2:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicAnonymous">
<security mode="None"/>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="Extended">
<serviceMetadata httpGetEnabled="true"/>
<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
</behavior>
</serviceBehaviors>
</behaviors>
<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="false" logMessagesAtServiceLevel="false" logMessagesAtTransportLevel="true" maxMessagesToLog="3000"/>
</diagnostics>
<services>
<service behaviorConfiguration="Extended" name="AnCWCFWebService.ProductInfoProvider">
<endpoint address="" binding="basicHttpBinding" name="ASMX" bindingConfiguration="BasicAnonymous" contract="AnCWCFWebService.Interfaces.IProductInfoProvider"/>
</service>
</services>
</system.serviceModel>
404 BadRequest Due to IIS Configuration...
If you are receiving a 404 BadRequest error from IIS after attempting to modify host headers in IIS, this is common, but there is a fix!
Fix By Making IIS Configuration Changes
How can WCF support multiple IIS Binding specified per site?
Fix By Making WCF Code Modifications
Alternatively, the following article explains how one developer solved this issue with a combination of configuration and code:
Well, that was fun! An adventure in WCF, SSL, and Host Headers
http://geekswithblogs.net/rakker/archive/2008/07/03/123562.aspx
The article references two important links...
The first one explains how to properly set the host headers in IIS:
Configuring Server Bindings for SSL Host Headers (IIS 6.0): http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/8d9f2a8f-cd23-448c-b2c7-f4e87b9e2d2c.mspx?mfr=true
After getting host headers working, you'll find that...
"you can't have more than one host
header for IIS or wcf will break"
The solution to working around this limitation is found within this article, and there is also a comment on the GeeksWithBlogs.net article above that provides an enhanced variation:
WCF: This collection already contains
an address with scheme http
If you are still experiencing trouble, let us know in the comments below...
If the Service is Not Working...
My experience with WCF is that it is very tricky at times, especially with configuration. If one is following best practices and not doing anything non-standard, the great majority of deployment problems are the result of a botched configuration file.
In theory (not so much in practice, due to architectural differences), setting up a WCF service on IIS should be no different than setting up a typical virtual directory and corresponding application for web application or for an ASMX web service.
Therefore, I recommend that if this is the first WCF service you are exposing to the Internet, follow the same simple approach you would take when exposing your first website. Basically, create a new sample "WCF Service Application" (this is available in the Add New Project dialog, under the Web section of C# or VB).
Once you have it working, follow your deployment practices to move it into a production sandbox and test it locally. This sandbox would preferably already have some web sites or web services installed and known to be accessible from the Internet, in order to eliminate any doubt about the typical network configuration issues. If you have a sample ASMX web service that is already successfully exposed on the Internet from that server, that would be best.
Next, try testing the the ASMX and the WCF services from web browser, both locally on the server, internally on other desktops and then finally externally.
Testing URLs
We want to test accessing the standard SVC and ASMX file from the web browser in all the varieties of URL flavors that are available and relevant. The results should be similar, with summary page about he service rendering in the window. The difference will be that the ASMX web service's summary will likely allow you to execute the web methods on the service if that feature has not been disabled in the web.config file.
Compare the results of browser fetches of the following styles of URLs...
http://localhost/WcfService1/Service1.svc
http://localhost/WcfService1/Service1.asmx
http://MachineName or MachineFQN/WcfService1/Service1.svc
http://MachineName or MachineFQN/WcfService1/Service1.asmx
http://MachineLocalIP#1/WcfService1/Service1.svc
http://MachineLocalIP#1/WcfService1/Service1.asmx
http://MachineLocalIP#2/WcfService1/Service1.svc
http://MachineLocalIP#2/WcfService1/Service1.asmx
http://ExternalIP/WcfService1/Service1.svc
http://ExternalIP/WcfService1/Service1.asmx
All of these tests should return similar results.
Testing Service Methods
If you feel like it, go head and test some web methods on the ASMX web service for any of the tested URLs, from the web browser. You'll soon see that we can test ASMX web services a different way also...
Next we'll test web methods on both the WCF service and the ASMX web service by using the WcfTestClient.exe application that is found in the Visual Studio 2008 distribution (C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE).
You will need to add the services through the File->Add Service menu item, typing in the URL above for each service URL that you wish to test. Make sure to include the filename of the SVC and ASMX files. If all is well, the MEX endpoint that is enabled by the "httpGetEnabled" attribute of the <serviceMetadata/> element in the web.config file will return the data that is necessary for the utility to operate, thereby populating the tree with the inventory of our service methods like this:
From this point, it will be useful to refer to the following to resources:
WCFTestClient: http://msdn.microsoft.com/en-us/library/bb552364.aspx
What's New for WCF in Visual Studio 2008: http://msdn.microsoft.com/en-us/magazine/cc163289.aspx
Conclusion
If you make it this far, then I do not expect any other issues and you should now attempt to compare the setup of the samples to the WCF service that you are attempting to publish to the Internet, and hopefully the differences will be obvious.
Remember to treat the WCF service like an ASMX web service during you diagnostics, assuming that the web.config is known to be set up correctly.
If you are still unable to make things work, check this guide for further technical advice:
Deploying an IIS-hosted WCF service: http://msdn.microsoft.com/en-us/library/aa751792.aspx
Finally, if all else fails, just wrap your WCF service in an ASMX web service:
How to: Expose WCF service also as ASMX web-service: http://kjellsj.blogspot.com/2006/12/how-to-expose-wcf-service-also-as-asmx.html
You just need to configure your host header in the IIS so that the links in the WSDL references will use the donmain name rather local machine name.
Check out
Steps to configure IIS host header so that WCF will use domain name in WSDL references.
Why not just assign a new IP address to the server instead of messing around with hostnames? A Windows Server can have multiple IP addresses for the same NIC.
Here is an article that talks about it.
I have a WCF service up and running and am able to communicate between the service and a .Net 2.0 Client using basicHttpBinding.
I now need to lock down the WCF service so that it can only be called by authenticated clients.
I have control over the clients that will be calling my service. The clients are part of a product that will be installed in the wild and "phoning home" to push and pull data. The client app is written for .Net 2.0 framework and cannot be upgraded to 3.0 or 3.5 at this time. I cannot add windows user accounts to the client machines.
What are my options for securing the WCF Service and being able to authenticate from my .Net 2.0 clients? Also, data needs to be passed over https.
I've been searching the web, and feel like I'm on a wild goose chase.
You can configure a WCF endpoint to use 2-way SSL authentication. That means that you can require clients to present an X.509 certificate that confirms their identity whenever they make a request to the service.
On the server side of things, you can use one of the built-in validation schemes in WCF or provide your own validation logic to check the X.509 certificate.
If you were hosting your service in IIS, it would be trivial to configure SSL to require client certificates at the transport-level. However, you can find a good guide on how to implement this behaviour in a self-hosted WCF service here:
http://leastprivilege.com/2007/08/25/certificate-based-authentication-and-wcf-message-security/
I haven't tried this myself but, since this creates a security requirement at the message-level, I think you will have to use wsHttpBinding to enforce it in your WSDL contract, since imposing security requirements to access a web service is part of the WS-* standards.
If you have to use basicHttpBinding, you can try this solution instead that moves things up at the transport-level:
http://leastprivilege.com/2007/08/26/certificate-based-authentication-and-wcf-mode-independent/
Hope this helps
OK so, with SSL you have transport level security; which is fine, that protects the message from sniffing and changing.
So now you have options; do you need the validation to be silent, or can you prompt the user for a username/password when your program starts? If it must be silent then you can go the client side certificate as mentioned (although that is painful, you will need to generate the certificates yourself and validate them, so you need to look at running your own certificate authority). Or you can embed a custom header in the message which contains a client ID and do it the kludgey way.
If however you can prompt for a username and password then you authenticate that way and plug it into a database lookup quite easily using a custom authenticator, or even using the ASP.NET membership database.
Here is what I ended up doing which seemed to be the simplest solution in our situation, which is pretty small scale with only a handful of web services exposed:
Secured the transport with SSL
Clients first login to the web service by calling a Login method on the web service. If the login succeeds, it returns an encrypted FormsAuthenticationTicket to the client.
Clients must then supply the forms authentication ticket with each web service call. Each method checks if the ticket is valid and if so it does its work. If the ticket has expired or is invalid, clients must re-authenticate.
Hope that helps someone...
You security will be covered by the ssl.
For authentication you have two options - basic (username and password) or certificate.
Here is a video that demonstrates configuring certificate authentication.
In that you are configuring the security elements of the basicHttpBinding shown below:
<basicHttpBinding>
<binding name="basicHttp">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="Certificate"/>
</security>
</binding>
</basicHttpBinding>
There is also a good page on this here. Google on clientCredentialType and you should find yourself on the right track soon enough.
For setting up the client certificates you are after the wse* policy file.
You will need to work out how you will provide the client certificate to the various sites.- that depends on security concerns of the project. There are various ways (none of which I can remember sorry, I last did this for wse* to wse* about two years ago so the details are forgotten, but it is certainly possible, took a few days solid research to find a good method).
Using SSL certificate is the only option for .NET 2.0 client accessing WCF service as basicHttpBinding provides no security. By using SSL, you are securing the whole transport channel.
Check the link http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=15892 . It covers WCF Security covering all scenarios.
To get free SSL certificate please visit http://www.comodo.com/ or http://www.instantssl.com/ and try out in your application.