What is the best approach to implementing authorisation/authentication for a Windows Forms app talking to an IIS-hosted RESTful WCF Service?
The reason I ask is I am very confused, after sifting through different articles and posts expressing a different method and eventually hitting a ~650 page document on WCF Security Best Practices’ (http://www.codeplex.com/WCFSecurityGuide) I am just uncertain which approach is the BEST to take and how to get started on implementation, given my scenario.
I started with this article ‘A Guide to Designing and Building RESTful Web Services with WCF 3.5’ (http://msdn.microsoft.com/en-us/library/dd203052.aspx) and a PDC video on RESTful WCF services, which was great and helped me implement my first REST-friendly WCF service,
After I had the service working, I returned to implement security, see. ‘Security Considerations’ (quarter down the page) and attempted to implement a HTTP Authorization header as per the instructions, however I found the code to be incomplete (see how ‘UserKeys’ variable was never declared). This is the point at which I tried to research more on how to do this (using a HMAC hash with the ‘Authorization’ HTTP header, but could not find much on google?) it led me to other articles regarding message-level security, forms auth and custom validators and frankly I am not sure which is the best and most appropriate approach to take now.
So with all that said (and thanks for listening up till now!), I guess my main questions are,
– Which security implementation should I use?
– 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.
– Should I even really be concerned about anything other than plain text if I am using SSL?
As said, .NET 3.5 win forms app, IIS-hosted WCF service, however what is important is I wish any and all WCF services to require this authorization procedure (however it should be, session, http header or otherwise) as I do not want anybody to be able to hit these services from the web.
I know the above post is large but I had to express the route I have already been down and what I need to accomplish, any and all help is greatly appreciated.
PS: I am also aware of this post How to configure secure RESTful services with WCF using username/password + SSL and if the community suggests I move away from REST for WCF services, I can do this, however I started with this to keep consistency for any public APIs to come.
I think it’s important I state how I am accessing my WCF Service (contacting the service is working, but what is the best way to validate credentials – and then return the Member object?):
WebChannelFactory<IMemberService> cf = new WebChannelFactory<IMemberService>( new Uri(Properties.Settings.Default.MemberServiceEndpoint)); IMemberService channel = cf.CreateChannel(); Member m = channel.GetMember('user', 'pass'); Code that was half implemented from MS article (and some of my own for testing):
public Member GetMember(string username, string password) { if (string.IsNullOrEmpty(username)) throw new WebProtocolException(HttpStatusCode.BadRequest, 'Username must be provided.', null); if (string.IsNullOrEmpty(password)) throw new WebProtocolException(HttpStatusCode.BadRequest, 'Password must be provided.', null); if (!AuthenticateMember(username)) { WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.Unauthorized; return null; } return new Member() { Username = 'goneale' }; }
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.