WCF 用户身份验证和授权

Posted 2023-05-07

【中文标题】WCF 用户身份验证和授权

【英文标题】：WCF User Authentication & Authorization

【发布时间】：2013-10-02 08:03:26

【问题描述】：

我需要找到一种方法来验证/授权 WCF 服务中的用户。我正在使用存储用户凭据的外部身份验证服务。

例如。 “Bob 使用我们的登录方法，我们将凭据发送到身份验证服务，该服务让我们知道这些凭据是否正确。” 如果 Bob 发送另一个请求，我们需要知道 Bob 是否已经通过身份验证。

现在正在客户端上创建一个会话，但它需要移动到服务器端。我们不能依赖客户来确保安全。

这可以通过使用安全 cookie 来解决吗？或者你们有没有更好的建议？

编辑！我只能使用认证服务器，无权访问它

【参考方案1】：

您所描述的问题是一个众所周知的问题，它有（至少）两个标准化解决方案。

使用 WS-Trust 进行联合

第一个选项是基于 SOAP 的选项，它使用基于 WS-Trust 的活动联合。在这个解决方案中：

您的客户端向身份验证服务提供凭据 如果凭据有效，则身份验证服务会向客户端返回一个签名（和加密）的令牌。它被加密，因此令牌中包含的任何信息都保持机密 - 甚至客户端也无法读取它。它使用属于您的 WCF 服务的公钥加密。它使用属于身份验证服务的私钥进行签名。 客户端将签名/加密的令牌提交给您的 WCF 服务。该服务可以解密它，因为它拥有用于解密的私钥。它可以信任它，因为它是由身份验证服务签名的。 根据解密后的令牌内容，服务可以建立客户端身份并做出授权决策。

在这个模型中，通常的术语是：

您的身份验证服务

Security Token Service

您的 WCF 服务是

依赖方

您的客户是

客户

这听起来很复杂，但在使用 Windows Identity Foundation 的 .Net 和 WCF 中得到了很好的支持。有很多可用的示例，其中大部分（可能全部）都可以通过 WCF 配置而不是代码来完成。

这非常适合客户端具有加密功能（如您的 .Net 客户端）和存在良好框架（如 WIF）的场景。对于浏览器和某些手机等低规格客户端，或者您无法控制客户端的情况，它并不是那么好。

常用于企业场景，包括企业到企业联合。它在互联网场景中使用较少。

它的优点是

它是标准化的，因此通常得到框架的良好支持 这意味着您的 WCF 服务永远不必处理客户端凭据（= 更安全） 它可以很容易地切换到不同的身份验证服务（因为它是标准化的）。例如，本地 AD 和 Windows Azure AD 都支持这一点，其他独立的身​​份服务也是如此

可以在此处找到概述：

http://msdn.microsoft.com/en-us/magazine/ee335707.aspx

Google 会向您展示更多的演练和示例。

使用 OAUth 2 进行联合

在这个解决方案中：

客户端显示认证服务提供的一些UI（一般是网页） 用户在该 UI 中输入他们的凭据，身份验证服务进行身份验证并最终将令牌返回给客户端。令牌的性质没有标准化，也没有加密。一般来说，它至少会被签名。 客户端将令牌与每个请求一起提交给 WCF 服务 WCF 服务像之前的解决方案一样对令牌进行身份验证

在 OAuth 术语中：

您的身份验证服务是

授权服务器

您的 WCF 服务是

资源所有者

您的客户是

客户

再一次，这听起来很复杂，但它在 .Net 中得到了相当好的支持。虽然目前可能不如 WS-Trust 方法好。它由 Windows Azure AD 和客户端支持，使用 Windows Azure 身份验证库。其他服务可能会使用这种方法 - 例如。脸书。

这在哪里很有效

您的客户端规格低或不支持加密（例如浏览器或某些手机） 您无法控制客户端（例如，第三方应用程序正在访问您的服务）

它在 Internet 应用程序中非常常用，您作为 WCF 服务的所有者不一定知道用户或客户端。在某些方面它是一个不太完整的标准（例如，它没有准确定义身份验证的发生方式），因此不太容易切换到其他授权服务器。

它的优点是：

它更简单，因此具有更广泛的平台支持 它越来越受欢迎，因此对库的支持也越来越好 用户从不将他们的凭据输入到您的 UI 中，只输入到身份验证服务器中，因此它更有可能被信任（在互联网场景中） 它具有控制授予客户端的权限范围和撤销这些权限的内置方式，因此它在互联网场景中更受信任

对此的官方 .Net 支持位于 Windows Azure AD 身份验证库中

http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx

还有其他开源组件，例如 DotNetOpenAuth

http://dotnetopenauth.net/

哪种解决方案最适合您，主要取决于您的身份验证服务的性质。以及您是在企业还是互联网场景中。如果授权。服务可以很容易地调整为 WS-Trust 安全令牌服务 (STS)，那么这将是一条很好的路线。如果向身份验证添加一些 Web UI。服务可行，OAuth可能会更好。

或者，如果这两种方法都不可行，您可以从一种方法中借用模式并使用它，而无需采用完整的标准。

祝你好运！

【讨论】：

感谢您的这篇详尽的帖子。我忘了说我没有访问身份验证服务器的权限，我只能使用它。所以我会尝试制作自己的令牌系统

大声笑，好的。正如我所说，这些模式应该很有用:o)