WCF - 在标头中配置客户端/服务器身份验证?

发布于 2024-08-12 16:38:00 字数 1416 浏览 9 评论 0原文

我有一个 WCF 服务,需要接收客户端凭据,并根据我的身份验证方法维护某种基于角色的数据。

客户端将驻留在许多不同的系统上,因此,每个客户端都将拥有唯一的用户 ID 和密码。

我正在使用 basicHttpBinding 并阅读了几篇文章,例如这篇文章, http://nirajrules.wordpress.com/2009/05/22/username-over-https-custombinding-with-wcf%E2%80%99s-channelfactory-interface/,描述了该过程。

所以我正在寻找的是,如果有人有一个像这样配置的完整客户端/服务器来查看,这样我就可以从中得出我自己的解决方案。

我想做的是将用户名和密码传递到每个请求的标头中,在失败时传回某种 SecurityTokenValidationException,或者在通过时继续。

谢谢。

更新

我在客户端和服务器上使用具有以下配置的 wsHttpbinding:

  <wsHttpBinding>
    <binding name="wsHttpEndpointBinding" >
      <security mode="TransportWithMessageCredential">
        <transport clientCredentialType="Basic" />
        <message clientCredentialType="UserName" />
      </security>
    </binding>
  </wsHttpBinding>

客户端对服务器的调用如下:

ServiceReference1.ServiceClient myClient = new ServiceReference1.ServiceClient();

myClient.ClientCredentials.UserName.UserName = "billuser";
myClient.ClientCredentials.UserName.Password = "mypassword";

Response.Write("Data from WCF Service: " + myClient.GetData(1));

我想我需要一些帮助来链接服务器上的 CustomUsernamePasswordValidator 因为我仍然收到“...无法激活。”错误。

I've got a WCF service that will need to receive client credentials, and maintain some kind of role-based data, based on my auth method.

The clients will reside on many different systems, and as such, each client will have a unique userID and pw.

I'm using basicHttpBinding and have read a few articles, such as this one,
http://nirajrules.wordpress.com/2009/05/22/username-over-https-custombinding-with-wcf%E2%80%99s-channelfactory-interface/, that describe the process.

So what I'm looking for is if someone has a full client/server configured like this to take a look at so I can derive my own solution from this.

What I'd like to do is have the username and password passed in the headers for each request, passing back some kind of SecurityTokenValidationException on fail, or continuing if passing.

Thanks.

UPDATE

I'm using the wsHttpbinding with the following config on both the client and server:

  <wsHttpBinding>
    <binding name="wsHttpEndpointBinding" >
      <security mode="TransportWithMessageCredential">
        <transport clientCredentialType="Basic" />
        <message clientCredentialType="UserName" />
      </security>
    </binding>
  </wsHttpBinding>

And the call out to the server from the client as follows:

ServiceReference1.ServiceClient myClient = new ServiceReference1.ServiceClient();

myClient.ClientCredentials.UserName.UserName = "billuser";
myClient.ClientCredentials.UserName.Password = "mypassword";

Response.Write("Data from WCF Service: " + myClient.GetData(1));

I think I need a bit of a hand with linking up the CustomUsernamePasswordValidator on the server as I'm still getting the '...could not be activated.' error.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

怪我太投入 2024-08-19 16:38:00

您需要使用 basicHttpBinding 吗?该绑定实际上只是为旧版 WS-BasicProfile 实现(即 ASMX)提供支持。如果您的客户端也是 .NET/WCF,我强烈建议使用 wsHttpBinding,它提供了大量开箱即用的安全选项。您可以将证书、用户名/密码等与传输和/或消息安全一起使用,而无需自己编写任何安全内容。只需配置即可运行 (CAG)。

如果您需要直接从代码访问安全凭证信息,则服务本身可以通过 OperationContext 获取安全凭证信息。但是,如果您的代码确实需要访问它,我建议编写一个行为来从 OperationContext 中提取相关信息,并将其放置在更特定于应用程序的内容中,这样您就不必在需要访问的任何地方引用 System.ServiceModel有关操作上下文的信息。

Are you required to use the basicHttpBinding? That binding is really only there to provide support for legacy WS-BasicProfile implementations (i.e. ASMX). If your clients are also .NET/WCF, I would highly recommend using wsHttpBinding, which provides a plethora of security options out of the box. You could use certificates, username/password, etc. with transport and/or message security and not need to write any of the security stuff yourself. Just configure-and-go (CAG).

Security credential information is available to the service itself via the OperationContext, in case you need to access it directly from your code. If your code does need to access it, however, I would recommend writing a behavior to extract the pertinent information from the OperationContext and place it in something more application specific so that you don't have to reference System.ServiceModel everywhere you need to access information on OperationContext.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文