将 HttpContext.Current.User.Identity 传递给 WCF答案

【问题标题】：Passing HttpContext.Current.User.Identity to WCF将 HttpContext.Current.User.Identity 传递给 WCF
【发布时间】：2012-03-10 20:53:28
【问题描述】：

寻求一点建议（或者甚至是直接的答案）。

我有一个 MVC3 网站。我还运行了一组 WCF 服务（现在一切都在同一个盒子上）。

我正在尝试做的是对客户端进行身份验证（该部分工作正常），然后将该经过身份验证的用户传递给各种 WCF 调用。

目前我已经在Global.Asax 中连接了Application_AuthenticateRequest() 方法，归结为创建一个新的GenericIdentity & GenericPrincipal，然后将该主体分配给HttpContext.Current.User：

...
GenericIdentity identity = new GenericIdentity(userName);
GenericPrincipal principal = new GenericPrincipal(identity, null);
HttpContext.Current.User = principal;
...

这部分似乎也运行良好。

但是当我点击我的服务时，我已经完全失去了我设置的用户。值为空或 false。

我注意到的一件主要事情是，在客户端，HttpContext.Current.User.Identity 对象的类型为 {System.Web.Security.FormsIdentity}，但在服务中它的类型为 {System.Security.Principal.WindowsIdentity}。

根据我读过的一些内容，这听起来像是简单地修改我的web.config 使其包含aspNetCompatibilityEnabled="true" 可能足以使其正常工作。但这不是我所看到的。所以要么我不了解所有内容（一个很好的可能性），要么我搞砸了（另一个很好的可能性）。

所以我的问题。这甚至可能吗，如果是这样的话 - 对我所缺少的东西的想法？我注意到其他一些人发布了类似的内容，但从未收到过明确的答复（请参阅here 和 here）。

非常感谢任何建议。

【问题讨论】：

当您在当前用户上下文中专门设置 GenericIdentity 时，您说看到 FormsIdentity 很奇怪。你是不是搞混了？

标签： asp.net-mvc wcf authentication cookies httpcontext

【解决方案1】：

我无法直接回答您的问题，但希望能帮助您找到明确的答案。

您有 2 个服务层，似乎您的要求是在所有层之间共享身份验证身份。

因此，原则上，您需要（至少）相同的身份验证机制或算法或技术来实现此目的。但此时您使用的不是相同的（当您看到FormsIdentity 和WindowsIdentity 时注意到了）。

事实：

您将需要相同的身份验证机制。
无论您使用什么机制，都需要支持您想要进行的第三个跃点（这意味着您可以将用户的身份用于第三个服务，而无需实际拥有重新验证的凭据）。

问题：

如果您继续使用表单身份验证，则需要使用 WCF 服务重新进行身份验证（当然还需要提供身份凭据，this可能帮助）。除非您保留用户用来验证他/她自己的密码，否则我觉得很难做到这一点，这通常是个坏主意。
如果您继续为您的站点使用 Windows 身份验证，那么如果用户从 Intranet 登录，您就会遇到问题。 Kerberos（Active Directory 使用 Kerberos）的有趣之处在于，它让用户无需重新验证即可访问远程资源……但此用户身份令牌仅适用于 1 跳。虽然您的 WCF 和 MVC 服务在同一台服务器上，但它会起作用，但如果您最终将您的 WCF 服务拿走……这是第三个框边界……第三个跃点，Kerberos 票证将不够好。

所以...由于不了解您的要求，我首先建议您：

忘记 WCF 层上的身份验证
将您的 WCF 服务访问设为私有（发挥您的网络技能...防火墙等）。我首先让 WCF 在不侦听端口 80（或 443）的单独 IIS 网站上运行，并确保防火墙阻止从 LAN 外部的 IP 访问您的新 WCF 端口（或者更好的是，在您的白人之外）列表（现在是本地主机））。
将用户身份指定为每个 WCF 调用的参数。或者，如果您感觉很疯狂，请探索通过 SOAP 标头指定用户身份的方法（如果您的 WCF 使用 SOAP）。自定义标题也应该做得很好。您将信任您的网站在授予用户访问您的 WCF 服务之前正确地质询和验证用户。

到目前为止，我已经多次看到此运行。没有对私有服务进行身份验证是一个很好的性能交易，但您需要采取预防措施，因为一般来说，大多数 IT 攻击来自内部 LAN。

【讨论】：