I am working on an app that has several clients - Desktop, Mobile Device, Web Portal. We're moving to an SOA kind of architecture and will be using WCF.
The WCF story is great when it comes to using netTcp+transport/message security+Windows authentication (or even UsernameToken and a custom UsernameValidator provider) on the Desktop and Web Portal side.
Where it totally breaks down is on the compact framework side...the subset of WCF it supports is so limiting. I was resigned to simply using basicHttp + Username/Password in the headers all over SSL, but it seems that you cannot add headers when on the compact framework stack (no OperationContextScope) - so that leaves me with including username/password as parameters for EVERY SINGLE operation method in the service.
Please tell me I am wrong and there is a better way.
Your best bet is going to be to expose a WCF end-point that conforms to the WS-Security standards.
You should then be able to use those standards for message based security (most likely using X.509). Here's the MSDN link to get started:
Messaging in the .NET Compact Framework
An alternative solution is to pass a ticket (read: guid).
The client logs in (sends username and password). A randomly generated ticket is generated (guid again), cached on the server, and sent back to the client. This ticket is then passed back and forth instead of the username and password.
Of course, all of that is assuming you don't just want to utilize session state.
But in other words: I've had the same problem you've had. It sucks. This is how I got around it a bit so it was usable.
Anyway, another good reference is the WCF Guidance for Mobile.
Related
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
I have a third-party Java web service listening at three SOAP 1.1 WSDL endpoints. One of the endpoints is used to initiate the session and perform some high-level tasks, and the other endpoints are for subject-specific tasks reusing that initial authentication.
I'm building a C# WCF application to talk to the service, and I'd like to share the session cookie among the three client objects.
What's the VS2010 'best practices' way of sharing this cookie?
If this article is still the best answer, I can go with it, but I would appreciate some additional feedback, especially if .NET 4 introduced a simplification that I'm not finding on-line.
http://megakemp.wordpress.com/2009/02/06/managing-shared-cookies-in-wcf/
I can pretty easily create the first client and retain the session (new BasicHttpBinding myBinding; myBinding.AllowCookies = true), but I couldn't find an elegant way of saving off the cookie from the Connect response and reusing for the two auxiliary clients.
Any insights are appreciated.
I should note that I'm aware of CookieContainer and using Add Web Reference instead of Add Service Reference. That method is labeled as 'legacy' in most posts I've read, and I'd prefer to stay current...or as current as possible when working with SOAP 1.1.
The mentioned article is still valid. You have to use OperationContextScope and access message properties to get protocol specific data. This complexity is based on the fact that WCF architecture is protocol independent whereas ASMX architecture was HTTP protocol dependent.
It is true that ASMX (WebReference) is legacy technology but it is still present in .NET framework so if you know that you will never need nothing more the basic SOAP messaging without any advanced WS-* standard you can still use it and make your life little bit simple. Once you need anything more you can still refactor your code and use WCF with mentioned code to work with cookies.
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'm having a hard time getting my head around this, and Google just isn't being helpful.
I'm looking at converting some legacy code to use the following technologies: ASP.NET, WCF, jQuery.
The ASP.NET conversion isn't an issue, nor is accessing the WCF service for data, on the server-side.
However, what I'm having an issue with is potentially being able to secure the service so that I can return JSON-formatted data, requested via jQuery on the client-side, but lock it down to prevent external access.
For this particular implementation, it's not that big of a deal, since the ... quasi-Ajax-like functionality has been in place for quite a while, and there hasn't been abuse.
But, once this project is complete, I'd like to take what I've learned and convert another form, which is often abused, and allow for a slicker display.
If I want to do client-side calls to a Web service, am I stuck making my Web service open to anonymous access?
Short of securing the Web interface down to a specific subset of users (I see no issue with securing the added functionality to logged in users), are there any other strategies on securing a Web service in this scenario? Am I just overlooking something obvious?
Require an authenticated session for both the server-side page and its caller via ajax, with both behind HTTPS.
Another strategy is to use a token that is bound to the session during the last page load to confirm that the session itself has not been high-jacked. This is done when the client loads the page. The server tracks what the next token must be to confirm a valid request.
I have a Windows Service which performs a certain function, and then needs to send that information off to a webservice for processing. The webservice is hosted by a remote web application. I am trying to ascertain the best way to call the webservice(s) as each web application might be only 2.0, or 3.5 etc. In my windows service, I am defining each "client" in the app.config, e.g.
<Client WebServiceUrl="http://location.com/webservice.svc" Username="" Password="">
</Client>
The web application must implement two web services that are required for my windows service to run, however not sure the best way to implement the "rules" for the web application.
EDIT:
I'll try and rephrase..
The Windows Service runs every 30 seconds and obtains a list of information. The service supports multiple "clients" as shown above. When each client process is run, the data is collected and is then needed to be sent to the supporting web application.
The windows service does not know what to do with the data, it is just sending it. Each web application for a client would be in different locations, and could possibly be built in 2.0, 3.5, PHP, etc. All the windows service cares about, is that when it performs its processing for a client, it is able to send the data to the webservice location defined in the app.config of the windows service.
What I'm trying to determine is how to connect to the webservice (which I'm leaning towards WCF, however Basic or WS not sure), and what rules need to be defined for the web application in how to build the response.
If the Windows service is to support php applications etc, WSHttpBinding would not be an option, which would mean BasicHttpBinding would then work. The other thing to decide is whether or not to utilise a RESTful service or SOAP service.
Hope this makes more sense.
I'm not really clear on what you are doing.
It seems like you have 3 things: A Windows Service, and then a web service, hosted in a web app.
I think your question is, what to use, REST, ASMX, WSE or WCF, when interconnecting the Windows Service app with the remote web service.
ASMX, WSE and WCF are alternative programming models for the web service. REST is not a programming model. It is not like the other three.
ASMX and WSE will require that you use Web services and SOAP.
WCF can allow you to use Web services and SOAP, REST (XML or JSON) over HTTP, or a binary format over TCP, among other options.
Because it is flexible and current technology, I'd recommend WCF. ASMX is now termed "legacy technology" by Microsoft. Doesn't mean it won't work, but it will not get updates. (Much like WinForms versus WPF). WSE is no longer in mainstream support, as far as I know. For these reasons, I wouldn't recommend starting a new project on WSE, nor on ASMX.
WCF is more general than ASMX and can seem more complicated, for that reason. But once you make some choices and zero in on what you want (for example choose HTTP and REST, or choose binary and TCP), it's more powerful. WCF can be used as the programming model on both the client or sender (in your case, the Windows Service, I guess) and/or on the server (the web service hosted in the web app).
Using WCF on the client side does not imply you must use it on the server side, and vice versa. On the other hand, if you control the source code on both ends, I would recommend using WCF on both sides.
As for "how to implement the rules for the web app" - I don't understand what you are asking there. Maybe if you are more specific on the question there, someone will be able to help out.
Update: Based on your additional explanation, I'm going to suggest you look at the REST stuff in WCF for .NET 3.5. In PHP it's very easy to implement a REST-style service, and with WCF, the same is true for .NET. Now in your case the Windows service is the client and it is sending out a request, an update request, to various servers that reside on your customers' networks. According to REST principles, I'd make those outbound requests PUTs or POSTs, depending on the semantics of the call.
Then you could ship some example service code to your (uppercase) Clients, to get them started on building what they need to receive your outbound PUT/POST messages.
Security is a concern though. You didn't mention it at all, which is surprising. Security is not one of those things best deferred, so that you "add it on later". You should think about it early - it may affect the protocol choices you make. For example, if you need to mutually authenticate the clients and servers (the latter at your "uppercase" Clients' networks), then you may want to go with SOAP, which gives you good options on the protocol side for security. Secure Web services extensions (WS-Sec, etc) are well supported in WCF, but not sure about the status of this capability in PHP.