I have been tasked to implement a WCF service that makes use of NetMsmqBinding. I wrote the service and it works fine. The problem is that in the last minute they told me that there will be no Active Directory integration. So I don't know how to configure the security of the service. There is a VPN tunnel between the service's and the client's machines but they do not use the same active directory. Please advice. Any kind of help or tutorials would be appreciated.
The problem is that the service is not always online. That is why using WCF over MSMQ is preferred for this scenario. So I am sending one way messages through MSMQ - which works fine. My only problem is that I am new to WCF and am not familiar with WCF security. I would like to be able to sign and encrypt the messages since the information to be sent to the service is confidential. I would like to make sure that only authorized clients call the service. Any suggestions?
I'm not sure I understand your question so correct me, if I'm wrong. I have recently been woring on a WCF service that was hosted on a computer with no Active Directory available. We secured it using certificates. Is it an option for you? It's pretty painless (if you get past the 'put the certificate in the store and give the correct user access to it' part).
You should be able to take advantage of network transparency.
Use webservices to communicate from one system to the other. You might have to deal with extra latency, but it should still be usable.
Well first, you can use WCF's security, the WS-* stuff. Some info here:
http://blogs.msdn.com/motleyqueue/archive/2007/10/06/complementing-msmq-security-with-wcf.aspx
Second, you might find this blog to be helpful:
http://blogs.msdn.com/johnbreakwell/default.aspx
One of the articles there about cross-domain sending mentions this article (Cross-Enterprise Support):
http://msdn.microsoft.com/en-us/library/ms705127(VS.85).aspx
Which might help you configure it in general.
Thank you, Michael, but this information wasn't helpful...
I found this: http://www.codeplex.com/WCFSecurityGuide/Release/ProjectReleases.aspx?ReleaseId=14070 - a book from "Microsoft Pattern & Practices" which describes in detail the security in WCF - a must-read for every WCF developer.
Related
I have to use a number of functions provided by a government web service. I have no idea what they used to implement this service. Could have been COBOL for all I know.
My problem is that I've been trying to access this service using the security features provided by WSE3.0 but have had no luck. I'm consistently getting errors regarding the certificates.
After some research I've realized that WSE3.0 is essentially defunct and I should be using WCF. But, I'm only writing a client and most literature seems to refer to the services themselves.
Is there even such a thing as using 'WCF' to write a client? Should it matter which I use?
Thanks in advance.
Sure, WCF is a great choice for writing a web service client. Here is how to create the client ("add service reference"). After this you need to create the binding (just like in the service samples).
I am going to need a web service that receives a string via HTTP POST and processes it without any response to the client. However, since I'm not the one making the client (which will be cell phones) I am unable to use a generated client class to consume the service. The service would also need to be self hosted in a regular Windows service, if that matters.
As I'm not too experienced with web services nor WCF, I am frankly unsure if I can or should use WCF for this, but as it's the only type of web service I'm at least a little familiar with I figured it would be great to start out with one if at all possible.
I've been googling around quite a bit but haven't been able to find any good references to this, so I'd also be very grateful if someone has a link lying around to someplace that discusses it.
I think you need WCF Restful service with one way operation. Following link might help you:
A Developer's Guide to the WCF REST Starter Kit,
For the sake of argument, lets say that I've got a basicHttp WCF service. Besides implementing authentication (login/logout methods), what is stopping someone from just cracking open Visual Studio, adding a web reference to my website's service, and then playing playing around with my service? I'm not familiar with a method of stopping someone from doing this. The idea of someone downloading all of my Data/Operation contracts and then start playing around is keeping me up at night, and I like my sleep!
Discoverability is the driving factor behind Web Services and especially SOAs. The ability of anyone at all who can reach the service to pull up the WSDL, generate a proxy in Visual Studio (or some other tool), and start using the service is one of the main reasons to create a web service!
I suppose you could generate all the client proxies and then disable the mex endpoint, but that pretty much cripples WCF, and even then it's only security through obscurity.
If you don't want any miscreant to start hitting your web service then either don't use the basicHttpBinding (which is designed for the express purpose of immediate and anonymous consumption) or host the service on a private network which only trusted clients can reach.
Some form of authentication or encryption is the only thing that can prevent this. You have to distinguish between those you want give access to, and those you don't. Give the ones you want to have access the certificate necessary to do encryption, or the username and password.
Don't give anything to the others.
I have a public WCF Service.
I have a WPF Desktop app & a silverlight app. My apps does not have any login requirements.
I want to make it difficult for another developer / website to make use of my service.
What's the best way to restrict access to my service? Use SSL and have the desktop / silverlight app store a token inside of it?
Yes, having a token / certificate be part of your installation is probably the most efficient way to make sure only computers with your own software will be able to access the service.
Also: do not publish the WSDL, e.g. turn off all metadata endpoints and "HTTP Get URL" and so on - don't publish your presence to everyone surfing around! ;-)
In addition, your app could also send some specific headers - although those are fairly easy to find and decipher.
And last but not least: you could come up with your own whacky binding, e.g. have some oddball combination, possibly your own serializer or message formatter. That's taking it quite far already, but it would definitely be possible to put up some hurdles there, too.
I need to protect my WCF web services and was thinking what is the best way of doing this. Its not really a ROLE / User situation - more of a "WHO CAN CALL THE WEB SERVICE".
I was thinking that i could use an IP? Is this the recommended way?
Anybody have any experience with this, I was thinking of have a table (sql) with all IPs that can access the web service but i didn't want to reinvent the wheel if something exists already.
I presume there is an event or similar when somebody access the webservice so i can check there ip? - Anybody have an example?
And i presume this can be accomplished with standard HTTP binding ?
I would appreciate any input anybody has
You can pretty easily restrict the calling IP's in your service using a service behavior.
There's an excellent CodeProject article including source code that shows how to do this. Since it's WCF and a WCF behavior, it's pluggable, too - you can add or remove it from your service as needed.
Marc
Really depends on the security level of the service. IP addresses alone are quite easily spoofed by a knowledgeable caller, so if it's a service that deals with sensitive information, I'd recommend something a little harder to break, like transport security (eg SSL) with client certificates. Very well supported by WCF and not as scary or expensive to use as you might think, especially if you control both the client and server (that way you can configure the client to ignore the cert's "trusted" status so you don't have to buy a commercial server cert).