this is B2B scenario, one client (at least for now).
Server environment:
WCF service, IIS6, .NET v3.5
Client environment:
dev shop is .NET 2.0/VS2005. Will be calling my WCF service.
Question: should i
(a) open WSDL gen for the client(not desirable for security reasons)
(b) send a WSDL file(s) to the client
(c) pre-compile Proxy into dll (on my side) and send it to the client
(d) ???
?
Any suggestions on what would be the best practice for this scenario, any pros/cons?
Thanks in advance,
Igor
Why is a publicly available WSDL not desirable for security reasons?
I may be willing to admit that publishing an API (which is basically what you are doing with WSDL) makes you a bit more vulnerable than if you didn't, but it would be wrong to assume that hiding the WSDL constitutes any kind of security. This is ironically called security by obscurity, and it will be broken by any determined attacker.
The web service should be secure in itself. WCF offers many security features, but that is perpendicular to your question.
I'd prefer publishing the WSDL. If you don't want to do that, or if there is a policy in place that says that you can't do that, then send the WSDL to the client team so they can use it as they wish.
Precompiling the proxy will only enforce your coding conventions on the client team, and they may not appreciate that - for example, I often prefer my proxies to be generated with the /i switch that makes the generated classes internal. I also like to be able to specify the .NET namespaces so that they fit the rest of my code. That would not be possible if I got a precompiled assembly (I would be able to use it anyway, but it would just annoy me).
If you don't want to actually publish the WSDL and make it available online for calling clients, then I would prefer the "send me the WSDL and XSD" approach.
That way, you still give the client calling you the ability and flexibility of creating the proxy the way they see fit.
I would only consider using a pre-compiled proxy in an assembly if the calling party was unable or unwilling to create the proxy themselves, and only if they asked me to supply that code in assembly form.
Marc
In order of preference I would be inclined to:
Have the service expose the WSDL (with security enabled)
Send a WSDL file to the service consumer
I was going to list option 3 as sending a proxy DLL but on second thought I wouldn't even list it as an option. It seems to me that shipping your client a proxy DLL opens up a big can of worms that I would not want to deal with.
The main problem is that you end up having to support executable code that is deployed at the client site. The proxy code could be generated by svcutil but if there is some sort of problem invoking the service I can just see the client calling you for support and telling you that your proxy is not working. Now, their claim is probably not correct but it's hard for you to prove it since you don't know what they are doing on their side. e.g.
Maybe they didn't install the proxy DLL?
Maybe there is some permission problem?
Maybe they don't know what they are doing (yeah, I know that never happens. :) ).
Maybe a .NET upgrade on their side affected your proxy?
You might even run into some versioning headaches when sending them new proxies.
If your customer is not that savvy instead of trying to help them by creating proxy DLL perhaps putting some time and effort into assisting them in getting the correct configuration and usage of your service would be a better approach?
Related
I've started a team project were each team needs to create a web service which will need to expose various methods. Our team has created a WCF web service and have had no problems with the other teams consuming our services except for one team, which I'll refer to as Team B. Team B created their web service using an older version of Java (no clue what version) which doesn't support metadata exchange.
Since we are all new to WCF, and web services in general, does anyone know of a way to solve this problem?
Thanks in advance
There are 2 types of metadata exchange - one is WSDL, and the other is MEX. WCF supports both. As long as you can open the web service url in a browser and see a WSDL file I'm in doubt if there is such an older java version that does not support it. MEX is a different thing but as long as you work with WSDL not interesting. You need to check with the Java team how their version supports generating clients from WSDLS (typcally there are command line tools like wsdl2java or IDE plugins) and then give them the WSDL url. It may be that there is a specific construct in the WSDL which they do not support in which case ask them for the error message.
just want to know what happens behind the seen when we create a wcf service in a project and add service reference in another project.
So to know it i am doing it all without Visual Studio i.e. writing service code in notepad files and using command line to run svcutil.exe.
My question is do i need to run svcutil at both side (service side and client side) to export and import metadata?
And what files at minimum are generated by svcutil.exe.
Thanks friends.
SvcUtil will generate a proxy class and a configuration file which will specify things such as the bindings the service uses, security credentials, read quotas, the address of the service, the contract etc. SvcUtil will generate the metatadata, serialization code and so on. You run SvcUtil on the service machine and the two files it gives you (proxy class and configuration file) may be used to create clients on different machines.
Typically these are also generated by the visual studio 'add service reference' feature so you don't really have to use SvcUtil. Visual studio actually uses SvcUtil behind
the scenes to generate the client proxy, so it seems a bit less 'messy' to use Visual Studio for generating client proxies.
In SOA terms some argue that generatting clients manually using SvcUtil or Visual Studio is not good practise since thes etools generate unnecessary code with too much coupling and don't give you much flexibility. You can separate your assemblies, such as your services, contarcts, proxies etc. and create service channels using the ChannelFactory class. This nice article is a proponent of the latter practice of generating client proxies.
I'm writing a server that needs to serve many clients. The traffic is NOT http (but rather some proprietary protocol on top of TCP). I'm not very familiar with commercial web servers such as IIS and Apache. Can anyone tell me if it's possible to write some sort of "extension" to run on top of one of these platforms so that I don't have to write the logic for the sockets? Or perhaps there is another way (not IIS or Apache) of doing it which is better?
My server is generally going to behave as a web service (gets request, queries db, sends response) however there is one scenario in which it stays connected to the client socket and sends updates at a given interval on that socket.
It seems reasonable for it to be a way to do this in a way that I'd only have to write my logic without the general logic of a server. Any ideas?
Thanks!
Good question, and its also good too look to leverage an existing web server - you get scalability and stability, effectively for free.
I've never done this myself, but it should be totally possible in IIS (i recommend v7+ for this, makes it easier).
You can set up a new web site through the administration tool, and assign it a port to listen on - this bit is pretty straight forward. You should set its Binding Type to net.tcp (this is a dropdown in the dialog to add a new website, you can't miss it).
You can then use either modules or handlers to implement the rest of your custom functionality. This article Developing IIS 7.0 Modules and Handlers with the .NET Framework is a good intro to the subject. Most of the doco out there about writing custom handlers and modules is focussed on the HTTP protocol, but there are some snippets floating around for TCP and/or net.tcp (because IIS and Apache are web servers, and web is synonymous with http). Another resource that may be useful is this: Configure Request-Processing for a Web Server (IIS 7)
Alternatively, you may consider changing your approach and do it as a net.tcp WCF service, with this you get the benefits of using IIS, the flexibility of choosing the protocol (can be statically configured, doesn't need to be compiled in), and you don't have to write handlers or modules.
I am faced with a WCF security scenario that isn't particularly well documented online.
I am developing a product licensing service in WCF that will be deployed along with our software (i.e. the service is running on the same PC as the client). This licensing service will be responsible for a number of things related to controlling use of our software and connecting to our remote licensing server for updates, revocations etc. Consequently it's not the kind of service I want spoofed, and I don't really want spoof clients communicating with it either.
As it's running on the same PC as the client can anyone suggest a security policy for this scenario? I'm particularly interested in authentication as most of the other security principles are straightforward. I'm reluctant to get into certificates if I can help it but as mutual authentication is a priority I'm beginning to think I may need to implement a custom 'challenge/verify' scheme between the service and client.
Any ideas? Thanks for reading.
Chris.
My suggestion is that no matter how much effort you put into that, there will be an attack vector that makes all of your effort null and void. One option is to use ILMerge to provide a single dll for your entire application, and store it encrypted on disk and create a loader that hits your service passing in the registration information. On your side, the service will validate the customer information and send back a decryption key. The loader would use the decryption key to decrypt the DLL in memory and load it dynamically.
The shortcoming of this approach is that a determined cracker could debug your application and when the DLL is decrypted, write the unencrypted stream to disk. Your only means of retribution would be to place some kind of marker on the DLL so that you can identify who was responsible for breaking your copy protection and bring legal action if it's found open on the Internet.
As long as you're deploying this software to the client, then you cannot store any kind of key inside it without risking compromise. Even if you use certificates, you cannot hide them from the client while still making them visible to your application. And if you embed the key in the assembly itself then someone will just pop it open using Reflector.
Assuming you don't care about outright cracking (i.e. patching the assembly's code to simply bypass the license checks), then there's one and only one correct way to implement this type of security and that is to mimic the way a PKI works, by using a remote server exclusively.
In a PKI, when a server needs to validate a client via a certificate, it checks that certificate against the certificate authority's CRL. If the CRL reports that the certificate is revoked then it refuses access. If the CRL cannot be contacted then the certificate is considered invalid.
If you want to implement this scenario then you need 3 logical services but not in your current configuration. What you need is a remote licensing server, a client, and an application server. The application server can, theoretically, reside on the client, but the key aspect of this app server is that it performs license checks against the remote licensing service and handles all of the important application logic. That way, "spoofing" the server becomes an almost impossible task because a casual cracker would have to reverse-engineer the entire application in the process.
This is significantly less safe than making the application server a remote server, and may not offer many advantages over simply embedding remote security checks in the client itself and scrapping the local app/licensing server completely. But if you are determined to take this 3-tier approach then the aforementioned architecture would be the way to go.
Again, this is assuming that you aren't worried about "direct" cracking. If you are, then you'll have to read up on techniques specific to that particular attack vector, and understand that none of them are foolproof; they can only slow an attacker down, never stop him completely.
I need to write an application that will proxify some other application (redirect all network traffic to other proxy server). Just like FreeCap, ProxyCap, etc. Can anyone here points me to API I should be using? Preferably the API that will work under 2k, XP, Vista and W7.
There are couple of APIs that you may use for this task.
One is LSP (Layered Service Providers) which is a Winsock2 API for writing Service Provider DLLs that can intercept all Winsock calls, like connect() or WSAConnect(). Read more on this here: www.komodia.com
Another is "detours" which is Microsoft's library for intercepting any API call. More on this here: research.microsoft.com/en-us/projects/detours/
Another is so-called IAT (Import Address Table) patching. Don't have a link for this.
Another approach is to write a DLL, name it "wsock32.dll", implement all Winsock2 calls that your target app uses, and simply place it to the folder with the target app. When the app will start, it will use the local "wsock32.dll" instead of the system one.
In general, you want to use some of these APIs to intercept the Winsock's connect() or WSAConnect() calls, do the connection thru the proxy in your code, and return your connected socked to the caller.
You probably want to read about DLL injection as well.
Can't you use some routing rules for that?
If not, write some simple server application in the technology You're in. I'm sure you'll find many examples in the network.