自托管 WCF REST 服务和基本身份验证

Question

我创建了一个自托管的 WCF REST 服务（带有 WCF REST Starter Kit Preview 2 中的一些额外内容）。这一切工作正常。

我现在正在尝试向服务添加基本身份验证。但我在 WCF 堆栈中遇到了一些相当大的障碍，这阻止了我这样做。

看来 HttpListener（自托管 WCF 服务在 WCF 堆栈中的低级别内部使用）正在阻止我尝试在自行生成的 401 Unauthorized 响应。为什么？

如果我忘记了这个 WWW-Authenticate 标头（微软似乎也这样做了），我就可以让身份验证工作。但这就是问题所在。如果我不发回 WWW-Authenticate 标头，则 Web 浏览器将不会显示其标准“登录”对话框。用户只会面临 401 Unauthorized 错误页面，而无法实际登录。

REST 服务应该可供计算机和人类访问（至少在 GET 请求级别）。因此，我觉得 WCF REST 在这里并不符合 REST 的基本部分。有人同意我的观点吗？

有人使用自托管 WCF REST 服务进行基本身份验证吗？如果是这样，你是怎么做到的？

PS：显然，我打算使用不安全的基本身份验证的前提是我也能让 HTTPS/SSL 为我的服务工作。但那是另一回事了。

PPS：我已经尝试过 WCF REST Contrib (http://wcfrestcontrib.codeplex.com/)有完全相同的问题。该库似乎尚未在自托管场景中进行测试。

谢谢。

Answer 1

不幸的是，我已经确定（通过分析 WCF 参考源代码以及用于 HTTP 会话嗅探的 Fiddler 工具的帮助）这是 WCF 堆栈中的一个错误。

使用 Fiddler，我注意到我的 WCF 服务的行为与使用基本身份验证的任何其他网站不同。

需要明确的是，这是应该发生的情况：

1. 浏览器发送 GET 请求，甚至不知道需要密码。
2. Web 服务器拒绝状态为 401 Unauthorized 的请求，并包含一个 WWW-Authenticate 标头，其中包含有关可接受的身份验证方法的信息。
3. 浏览器提示用户输入凭据。
4. 浏览器重新发送 GET 请求，并包含适当的 Authentication 标头和凭据。
5. 如果凭据正确，Web 服务器将响应 200 OK 和网页。
   如果凭据错误，Web 服务器将响应 401 Unauthorized 并包含与步骤 #2 中相同的 WWW-Authenticate 标头。

我的 WCF 服务实际发生的情况是这样的：

1. 浏览器发送 GET 请求，甚至不知道需要密码。
2. WCF 注意到请求中没有 Authentication 标头，并盲目拒绝状态为 401 Unauthorized 的请求，并包含 WWW-Authenticate 标头。目前为止一切正常。
3. 浏览器提示用户输入凭据。还是正常的。
4. 浏览器重新发送包含适当的 Authentication 标头的 GET 请求。
5. 如果凭据正确，Web 服务器将响应 200 OK。一切都很好。
   但是，如果凭据错误，WCF 将响应 403 Forbidden，并且不包含任何其他标头，例如 WWW-Authenticate。

当浏览器获得 403 Forbidden 状态时，它不会认为这是一次失败的身份验证尝试。此状态代码旨在通知浏览器它尝试访问的 URL 不受限制。它与身份验证没有任何关系。这会产生可怕的副作用，即当用户错误地输入用户名/密码（并且服务器以 403 拒绝）时，Web 浏览器不会重新提示用户再次输入凭据。事实上，网络浏览器认为身份验证已成功，因此会为会话的其余部分存储这些凭据！

考虑到这一点，我寻求澄清：

RFC 2617 (http://www.faqs .org/rfcs/rfc2617.html#ixzz0eboUfnrl）没有在任何地方提到 403 Forbidden 状态代码的使用。事实上，它对此事的实际说法如下：

如果源服务器不希望
接受通过 a 发送的凭据
请求，它应该返回 401
（未经授权）回应。回应
必须包含 WWW-Authenticate 标头
字段至少包含一个
（可能是新的）挑战适用于
请求的资源。

WCF 两者都不做。它既不能正确发送 401 Unauthorized 状态代码。它也不包含 WWW-Authenticate 标头。

现在在 WCF 源代码中找到确凿的证据：

我发现在 HttpRequestContext 类中有一个名为 ProcessAuthentication 的方法，其中包含以下内容（摘录）：

if (!authenticationSucceeded) 
{
   SendResponseAndClose(HttpStatusCode.Forbidden);
}

我捍卫 Microsoft在很多事情上，但这是站不住脚的。

幸运的是，我已经让它工作到了“可接受的”水平。这只是意味着，如果用户不小心输入了错误的用户名/密码，那么再次尝试的唯一方法是完全关闭其网络浏览器并重新启动以重试。所有这些都是因为 WCF 没有按照规范使用 401 Unauthorized 和 WWW-Authenticate 标头响应失败的身份验证尝试。

Answer 2

我找到了基于此的解决方案 链接和这个。

第一个是重写名为 CustomUserNameValidator 的类中的 Validate 方法，该类继承自 System.IdentityModel.Selectors.UserNamePasswordValidator：

Imports System.IdentityModel.Selectors
Imports System.ServiceModel
Imports System.Net

Public Class CustomUserNameValidator
    Inherits UserNamePasswordValidator

Public Overrides Sub Validate(userName As String, password As String)
    If Nothing = userName OrElse Nothing = password Then
        Throw New ArgumentNullException()
    End If

    If Not (userName = "user" AndAlso password = "password") Then
        Dim exep As New AddressAccessDeniedException("Incorrect user or password")
        exep.Data("HttpStatusCode") = HttpStatusCode.Unauthorized
        Throw exep
    End If
End Sub
End Class

技巧是更改异常“HttpStatusCode”的属性到 HttpStatusCode.Unauthorized

第二个是在 App.config 中创建 serviceBehavior ，如下所示：

<behaviors>
  <endpointBehaviors>
    <behavior name="HttpEnableBehavior">
      <webHttp />
    </behavior>
  </endpointBehaviors>
  <serviceBehaviors>
    <behavior name="SimpleServiceBehavior">
      <serviceMetadata httpGetEnabled="true"/>
      <serviceDebug includeExceptionDetailInFaults="false"/>
      <serviceCredentials>
        <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="Service.CustomUserNameValidator, Service"/>
      </serviceCredentials>
    </behavior>
  </serviceBehaviors>
</behaviors>

最后，我们必须指定 webHttpBinding 的配置并将其应用到端点：

<bindings>
  <webHttpBinding>
    <binding name="basicAuthBinding">
      <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Basic" realm=""/>
      </security>
    </binding>
  </webHttpBinding>
</bindings>

<service behaviorConfiguration="SimpleServiceBehavior" name="Service.webService">
    <host>
      <baseAddresses>
        <add baseAddress="http://localhost:8000/webService" />
      </baseAddresses>
    </host>
    <endpoint address="http://localhost:8000/webService/restful" binding="webHttpBinding" bindingConfiguration="basicAuthBinding" contract="Service.IwebService" behaviorConfiguration="HttpEnableBehavior"/>
</service>

Answer 3

是的，您可以为基于 REST 的 WCF 服务提供基本身份验证。但是，您必须遵循几个步骤才能获得完整且安全的解决方案，到目前为止，大多数响应都是所需所有部分的片段。

1. 将您的自托管服务配置为将 SSL 证书绑定到您托管 WCF 服务的端口。这与通过 IIS 等使用托管主机时应用 SSL 证书有很大不同。您必须使用命令行实用程序应用 SSL 证书。您不希望在不使用 SSL 的情况下在 REST 服务上使用基本身份验证，因为标头中的凭据不安全。以下是我写的 (2) 篇详细帖子，详细说明了如何执行此操作。您的问题太大，无法在论坛帖子中提供所有详细信息，因此我提供包含全面详细信息和分步说明的链接：

   应用和使用使用自托管 WCF 服务的 SSL 证书

   创建 WCF RESTful使用基于 SSL 的 HTTPS 提供服务并保护其安全

2. 将您的服务配置为使用基本身份验证。这也是一个多部分解决方案。第一个是将您的服务配置为使用基本身份验证。第二个是创建“customUserNamePasswordValidatorType”并检查凭据以对客户端进行身份验证。我看到上一篇文章回避了这一点，但是它没有使用 HTTPS，并且只是解决方案的一小部分；请注意那些未提供包含配置和安全性的端到端解决方案的指南。最后一步是查看安全上下文，以便在需要时在方法级别提供授权。我写的下面的文章将逐步指导您如何配置、验证和授权您的客户端。

   RESTful 服务：使用基本身份验证对客户端进行身份验证

这是将基本身份验证与自托管 WCF 服务结合使用所需的端到端解决方案。