I'm rather new to the WCF/IIS/MS web stack corner of the world so I'm hoping for some help evaluating my design.
What I need is a system that presents a number of resources as URIs. Each resource is a WCF web service providing a number of read and write operations. I need to provide username/password security for different resources.
How I'm hoping to make this work is to have IIS handle the security using the normal devices it uses for everything else. Then uses URL rewriting to remap everything to a single web service that will provide the correct resource based on the rewritten query string.
Will this work?
Am I missing something?
Is there a better way to do this?
If you happen to known of a really good tutorial for the bits and peaces (like what file does the security settings go in?) I would appreciate links?
For now there will be only a handful (2 to 20) users so static config files would be preferred for that as along as it won't cause problems later.
As I said, I hardly known jack in this domain so I don't really known what I don't known.
A few links I have found (don't even known yet if I'm looking in the right direction)
Fundamentals of WCF Security (assumes a bit more familiarity than I have)
Improving Web Security: Scenarios and Implementation Guidance for WCF (really long, book length)
Yes this sounds sane. For authentication you want to use ASP.NET membership module it provides a generic security API which can use intergrated (windows user), web form login, even LiveID or some custom authentication. In my experience MSDN has proven a good resource, here's a hands on article.
For web http binding WCF provides Uri rewriting out of the box using WebGet attribute.
for SOAP, the end point URL is the same, so I assume you want RESTful endpoint. If so, you need Basic auth over https not WS-Security.
Related
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 been challenged with the task of coming up with an authentication/authorization strategy for a pretty big WCF API. My task is to implement security on this API from clients who might be a website, a mobile app, or an internal/network admin user (which is pretty much the goal of any solid API).
I have looked into Windows Identity Foundation and federated security, but it relies on WS-* and my clients might be using REST or a non-SOAP protocol. So, my question:
Is there a security strategy (per method call, preferably using attributes) for WCF that does not rely on SOAP or involve reams of configuration files?
I realize there's probably no catch-all solution. I'm really looking for ideas or suggestions. This turns out to be a really tricky challenge.
Basic Authentication and HTTPS is a straightforward and "secure enough" solution for most API authentication requirements.
When you say "per method call", I'm getting the impression that are talking about authorization. For that you are probably going to have to roll something yourself. The upcoming Microsoft Web Api framework has some good extension points that will make this type of functionality much easier to implement. It shouldn't be too long before someone implements a reusable module for this framework that you can just plug in.
I'm in the process of setting up a WCF Data Services web service and I'm trying to sort out the security configuration. Although there's quite a lot of documentation out there for configuring WCF security, a lot of it seems to be outmoded or does not apply to my scenario.
Ultimately, I am planning on managing authorization of operations via change interceptors. Thus, all I really need is the simplest way to permit a client to pass credentials along with a request and to be able to authenticate those credentials against either AD or an ASP.NET membership provider (I'd much prefer the latter unless it makes things much more complicated).
I'm intending to manage encryption at the transport level (i.e. HTTPS).
I'm hoping that the eventual solution does not involve a huge web.config. Likewise, I'd much prefer to avoid writing custom code for the purpose of authentication.
In the following links you have a series of OData authentication options. If you don't know exactly what you want then that is a really good place to start and see what options you have.
Part1
Part2...
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 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.