0

For a client-server application, I want to develop a Web-Service which will be mainly used by the application itself (not intended for use by third parties at this time).

On the long run, however, exposing the WebService as some kind of API is generally desirable. Thus, I am already putting some thoughts in choosing a technology which allows "RESTifing" (terrible word-creation, I know ;-) ) a Web-Service easily at a later point.
WCF seems to be about right here as it provides the webHttpBinding but also other bindings which allow taking advantage of LANs and .NET clients.

The issue I now ran into is about authentification: All the authentification measures WCF provides seem to happen "outside" the actual service. However, I'd like to have a Login method (or something more "RESTful" as shown here under point 2).

For example, I imagine writing a Service like this one:

[ServiceContract]
public interface IUserService
{
   [ServiceMember]
   [WebInvoke(Method = "POST", WebUri="/Session")]
   public void Login(string username, string password);

   [ServiceMember]
   [WebInvoke(Method = "POST", WebUri="/Users")]
   public void Register(RegisterUserParameter parameter);
}

How do I integrate this service into the WCF so the methods preferably work over multiple sub-services in my service project?

When using the built-in WCF authentification, I need to supply username and password before making any service call. Thus, calls to either Register or Login would fail because I am not authentificated.

And how can I tell the WCF to remember which user is currently logged in using my service method? Is there any possibility to store something like a session cookie inside the WCF session on the client?

Or is it generally a bad idea to realize authentification under WCF the way I am trying to?

Should I maybe directly choose WebAPI at the cost of having a more complicated way to talk to the service in my client application?

Community
  • 1
  • 1
Matthias
  • 12,053
  • 4
  • 49
  • 91

2 Answers2

0

I think youmcan accomplish your goal easily if you rely on external authentication, like the FormsAuthentication.

The idea is to guard all your methods with the PrincipalPermission attribute with just ine exception - the Login method which is just supposed to append the Forms cookie to the response.

Some technical details can be found here in one of my blog posts:

http://netpl.blogspot.com/2010/04/aspnet-forms-authentication-sharing-for.html

Although I mention Silverlight as a client there, the solution is general and applies to any client technology. Also, the Login method is not mentioned in the blog post but its sole purpose would be to append the Forms cookie to the response.

This way the control flow of your clients would be to first calk your Login method and then, with the issues cookie, call all your other methods.

Note that this will only work in Http bindings so that this is not a general solution to any possible Wcf binding.

Wiktor Zychla
  • 47,367
  • 6
  • 74
  • 106
0

You can try the following:

  1. Create Login service with WCF login-password authentication. It will use e.g. subclass of UserNamePasswordValidator to validate username-password against DB etc. If validation is successful, return a token (e.g. GUID).

  2. All other service calls will be made by the client together with this token. Token verification can be made centrally, without modifying each service. To do so:

    • Pass your token in the header of your request
    • implement IDispatchMessageInspector, in its AfterReceiveRequest read token from header and validate it. If validation is successful, workflow will go inside your WCF service, if not you throw FaultException
    • attach your MessageInspector to services that need validation:


      ...

Maxim Zabolotskikh
  • 3,091
  • 20
  • 21