Question

对于客户端 - 服务器应用程序，我想开发一个主要由应用程序本身使用的Web服务（目前不打算供第三方使用）。

但是，从长远来看，通常需要将WebService作为某种API公开。因此，我已经在选择一种允许“RESTifing”（可怕的文字创建，我知道;-)）技术的一些想法，以便稍后轻松地使用Web服务。 WCF似乎就在这里，因为它提供webHttpBinding以及其他允许利用LAN和.NET客户端的绑定。

我现在遇到的问题是关于身份验证：WCF提供的所有身份验证措施似乎都发生在“实际服务之外”。但是，我想要Login方法（或更多“RESTful”，如here under point 2所示）。

例如，我想像这样写一个服务：

[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);
}

如何将此服务集成到WCF中，以便这些方法最好能够在我的服务项目中使用多个子服务？

使用内置的WCF身份验证时，我需要在进行任何服务调用之前提供用户名和密码。因此，对Register或Login的调用将失败，因为我未进行身份验证。

如何告诉WCF使用我的服务方法记住当前登录的用户？是否有可能在客户端的WCF会话中存储类似会话cookie的内容？

或者，按照我的方式在WCF下实现身份验证通常是一个坏主意？

我是否可以直接选择WebAPI，代价是在客户端应用程序中使用更复杂的方式与服务进行通信？

Answer 1

如果您依赖外部身份验证（例如FormsAuthentication），我认为您可以轻松实现目标。

我们的想法是使用 PrincipalPermission 属性保护所有方法，只有异常 - 登录方法，该方法应该将Forms Cookie附加到响应中。

我可以在我的一篇博文中找到一些技术细节：

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

虽然我在那里提到Silverlight作为客户端，但解决方案是通用的，适用于任何客户端技术。此外，博客文章中未提及登录方法，但其唯一目的是将表单Cookie附加到响应中。

这样一来，客户的控制流程就是首先调用登录方法，然后使用问题Cookie调用所有其他方法。

请注意，这仅适用于Http绑定，因此这不是任何可能的Wcf绑定的通用解决方案。

Answer 2

您可以尝试以下操作：

使用WCF登录密码身份验证创建登录服务。它将使用例如UserNamePasswordValidator的子类，用于验证对DB等的用户名 - 密码。如果验证成功，则返回一个令牌（例如GUID）。
客户端将与此令牌一起进行所有其他服务呼叫。令牌验证可以集中进行，无需修改每项服务。为此：
- 在您的请求标题中传递您的令牌
- 在头文件的AfterReceiveRequest读取令牌中实现IDispatchMessageInspector并验证它。如果验证成功，则工作流将进入您的WCF服务，如果不是，则抛出FaultException
- 将MessageInspector附加到需要验证的服务：
  
  
  
  
  
  
           ......

通过服务方式自定义验证？

2 个答案: