Well, I don’t have any experience with the REST capabilities of WCF, but I did wrestle a lot with understanding the implications of security choices in my WCF security question. As you’ve noticed, there’s a real lack of documentation on WCF out their on the Web, and my REST experience is limited, so take my answers with a grain of salt:
Which security implementation should I use?
and
Should I even really be concerned about anything other than plain text if I am using SSL?
Basic authentication over SSL is fine–after all, this how a great deal of existing Web sites authenticate users. (When you log into your Amazon shopping account, they’re just transmitting your username and password as you typed it over an SSL connection.) I understand what the article is saying about security and dictionary attacks, but blah blah blah, keep it simple and get something working first. UPS’s Plain Old XML API asks for the username and password with each call, so does FedEx’s POX API, so does PayPal’s SOAP API and CyberSource’s SOAP API–this seems to be fine enough for real world usage.
Is there any way to avoid sending the username/password with every WCF call? I would prefer not to send these extra bytes if a connection has been established at the beginning, which it will be before subsequent calls are allowed to be made after login.
This is one that I can answer a little bit more confidently. Usually, we try to design our public-facing WCF services to be stateless. That way, our WCF services scale easily; just throw more hardware and more servers and load balancers at the problem, and we don’t have to worry about sticky sessions or maintaining session state somewhere. So that means that if we want to “keep a user logged in,” then it’s not something that’s going to happen on the server.
What I ended up doing is treating my Web site as a trusted subsystem. It authenticated against the WCF service using a pre-shared X509 certificate, and if a customer was logged into the Web site via Forms Authentication, then it would send a customer username header to the service; a custom endpoint behavior on the WCF service would look for this header, see that it was installed by a trusted subsystem, and proceed to impersonate that user without the user’s password needing to be supplied or verified against the database.
Since you’re using REST, you could probably use a cookie on the client side to maintain state. If you use ASP.NET Compatibility mode, I think you can even use Forms Authentication directly, but I don’t know much about this approach since my WCF service was not IIS hosted.
In short, though, you’re going to have to send something with each request to identify the user, whether that is the username and password, just the username, or some hashed value stored in the cookie. If the last option, I guess you’d have to have some sort of Login() method or something on the service, something that would send an “okay, you’re logged if you pass in this hash value with future requests.” But not all REST clients will be expecting to receive cookies, just simple GET/PUT/POST/DELETE requests without any state.
If those were my shoes, I’d either go for the trusted subsystem approach (where a username header is supplied along with pre-shared credentials for the subsystem) or I’d require authentication on every call. The service would probably get some high-performance authentication caching mechanism if all those repeated requests became a problem.
Hope that helps a little bit.