24

我正在寻找一个允许在 WCF 中使用 RESTful 服务的配置文件，但我仍然希望能够“利用”成员资格提供程序以进行用户名/密码身份验证。

以下是我当前使用 basicHttp 绑定或 wsHttp w/out WS Security 的配置的一部分，这将如何改变 w/ 基于 REST 的服务？

    <bindings>
        <wsHttpBinding>
            <binding name="wsHttp">
                <security mode="TransportWithMessageCredential">
                    <transport/>
                    <message clientCredentialType="UserName" negotiateServiceCredential="false" establishSecurityContext="false"/>
                </security>
            </binding>
        </wsHttpBinding>
        <basicHttpBinding>
            <binding name="basicHttp">
                <security mode="TransportWithMessageCredential">
                    <transport/>
                    <message clientCredentialType="UserName"/>
                </security>
            </binding>
        </basicHttpBinding>
    </bindings>
    <behaviors>
        <serviceBehaviors>
            <behavior name="NorthwindBehavior">
                <serviceMetadata httpGetEnabled="true"/>
                <serviceAuthorization principalPermissionMode="UseAspNetRoles"/>
                <serviceCredentials>
                    <userNameAuthentication userNamePasswordValidationMode="MembershipProvider"/>
                </serviceCredentials>
            </behavior>
        </serviceBehaviors>
    </behaviors>
4

7 回答 7

3

这是一个关于使用 ASP.net 成员提供程序保护 WCF REST 服务的播客：

http://channel9.msdn.com/posts/rojacobs/endpointtv-Securing-RESTful-services-with-ASPNET-Membership/

于 2008-10-04T14:30:07.917 回答
2

我同意 Darrel 的观点，即 WCF 上的复杂 REST 场景是个坏主意。它只是不漂亮。

然而，Dominick Baier在他的最低权限博客上有一些很好的帖子。

如果您想查看 WSSE 身份验证支持并回退到 WCF 上的 FormsAuthenticationTicket 支持，请查看BlogService 的源代码。

于 2008-09-29T15:23:51.950 回答
1

在继续沿着这条通过 WCF 实现 REST 的道路之前，我建议您阅读Tim Ewald 的这篇文章。我尤其受到以下声明的影响：

我不确定我是否要在旨在将 HTTP 分解的层之上构建一个旨在将 HTTP 分解的层。

在过去的 12 个月里，我一直在使用 WCF 开发基于 REST 的东西，并且这种说法一次又一次地证明了自己是如此正确。恕我直言，WCF 带来的好处超过了它为进行 REST 工作引入的复杂性。

于 2008-09-27T14:50:32.483 回答
1

无论社区是否对 WCF 上的 REST 有意见（我个人持反对态度），微软都对它进行了抨击， http: //msdn.microsoft.com/en-us/netframework/cc950529.aspx

于 2008-11-30T19:06:45.853 回答
1

是的，与 Moto 一致，WCF Starter Kit 的链接是我看到的最接近使用自定义 HTTP 标头 ( http://msdn.microsoft.com/en-us/library/dd203052.aspx ) 进行凭据身份验证的东西。

但是我无法让这个例子继续下去。

于 2009-01-05T01:22:41.817 回答
1

尝试custombasicauth @codeplex

于 2009-03-22T09:49:13.400 回答
1

2012 年 1 月 23 日更新

自从我写了这个问题以来，我已经看到了一种更好的方法来保护 REST，比如在野外的 Web 服务。当我第一次听说它时，它听起来很复杂，但这个想法很简单，并且遍布整个网络，用于网络服务和其他安全通信。

它需要使用公钥/私钥。

1.) 端点的每个用户（客户）都需要注册您的 REST Web 服务

  • a.) 你给这个用户一个不应该与任何人共享的私钥
  • b.）如果需要，您还可以生成一个可以通过纯文本传输的公钥（这也将用于识别客户端）

2.) 用户的每个请求都需要生成一个哈希来对请求进行签名

  • a.) 其中一个示例可能如下所示：私钥 + 时间戳 + 编码的有效负载（如果足够小，例如要更新的简单用户信息）
  • b.）您采用这 3 个（或您决定的任何内容）并生成 1 路哈希（例如使用 hmac）
  • c.) 在通过网络发送的请求中，您包括公钥（以便服务器端知道谁在尝试发送此请求）、使用私钥生成的哈希和时间戳。

3.）服务器端点（您的 REST 方法）将需要使用客户端上使用的相同输入生成哈希。此步骤将证明客户端和服务器都知道与请求一起传递的公钥匹配的私钥。（这反过来意味着发送请求的用户是合法的，因为没有人知道私钥）

  • a.) 通过请求期间传递的公钥查找客户私钥

  • b.）将其他参数（时间戳和编码的有效负载）与您在上一步中找到的私钥一起使用，并使用相同的算法生成单向哈希（同样，hmac 是我在现实世界中看到的)

  • c.）产生的 1 路哈希需要匹配通过网络发送的哈希，如果不发回 400（或您认为是“错误请求”的任何 http 代码）
于 2012-01-24T02:58:27.217 回答