Question

我有一个N-Tier应用程序，其构建如下：
IIS7中的服务器端是一个ASP.Net应用程序，它在WCF服务上公开方法。这些方法使用EF4与DB通信。用Silverlight 4.0编写的客户端正在调用WCF服务上的方法。

WCF服务公开此方法：

[OperationContract]
void DeleteItem(int i_ItemId);

我不熟悉WCF服务，但我认为接下来的观察结果是正确的（如果我错了，请纠正我）：

1）如果我保留此方法/服务，任何知道我的服务位于http://www.mysite.com/myservice.svc的人都可以打开VisualStudio，打开“添加服务引用”并开始调用DeleteItem（）。

2）如果我尝试通过删除MEX端点来解决上述问题，仍然可以使用某些手动编码来调用服务。

因此，我试图解决这两个问题，开始学习WCF中的一些内置安全功能。快速浏览后，我想我可以使用以下绑定配置，以便拨打服务时需要用户名和密码：

  <wsHttpBinding>
    <binding name="RequestUserName" >
      <security mode="Message">
        <message clientCredentialType="UserName"/>
      </security>
    </binding>

尝试采用此解决方案时，我首先想到的是：当用户登录客户端时，客户端使用用户的名称和密码作为WCF调用的凭据。在服务器端，这些凭据将根据数据库进行验证。

现在的问题是，用户已知这些凭证（用户名和密码），因此他可以使用它们以我已经提到的方式调用DeleteItem（）。

从这里我想出了两个解决方案：

1）我将在客户端使用硬编码键，而不是使用userName和密码作为凭据。在XAP中加扰Dll会阻止某人获取此密钥。

2）当用户登录客户端时，服务器会发送某种临时令牌（GUID或其他内容），客户端可以使用该临时令牌在此通信会话期间对其进行身份验证（比方说，直到用户关闭）客户端）。

我的问题是：

第一个解决方案提供的安全级别是多少，以及您需要多大程度的努力才能破解它？

如果第一个解决方案非常容易破解，那么在WCF中是否有内置的方法来管理我在第二个解决方案中提到的令牌系统？

欢迎其他可以扩大范围的解决方案。

Answer 1

我不确定您要问的安全级别，但我不相信在XAP文件中存储用户名和密码，无论是否混淆。

我可以描述一个我在生产中实现的解决方案。

基本上，我使用标准的表单身份验证来保护应用程序，但我不像往常那样使用重定向，我使用ASP.NET表单身份验证附带的身份验证Web服务。这样我的登录就会通过Silverlight控件。我的应用程序有一个用户存储，我通过身份验证身份验证服务。

要挂钩验证服务，我在Global.asax中执行此操作：

protected void Application_Start(object sender, EventArgs e)
{
    AuthenticationService.Authenticating += new EventHandler<AuthenticatingEventArgs>(AuthenticationService_Authenticating);
}

void AuthenticationService_Authenticating(object sender, AuthenticatingEventArgs e)
{
    try
    {
        bool authenticated = //Call your user store here.

        e.Authenticated = authenticated;
    }
    catch (Exception ex)
    {
        e.Authenticated = false;
    }
    e.AuthenticationIsComplete = true;
}

您可以像使用<authorization>元素和<deny users="?">的表单一样保护网站的各个部分。浏览器将为您处理所有cookie。如果您想保护服务，请在Service /文件夹下拒绝未经过身份验证的用户。

此MSDN Post更详细地讨论了解决方案。

N-Tier App中的WCF和Silverlight 4.0：验证对服务的调用

1 个答案: