WCF用户身份验证和授权

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

使用WS-Trust的联合

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

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

在此模型中，常用术语是：

• 您的身份验证服务安全令牌服务
• 您的WCF服务是信赖方
• 您的客户就是客户

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

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

它通常用于企业方案中，包括企业到企业联盟。在Internet场景中使用频率较低。

它的优点是

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

可以在这里找到概述：

http://msdn.microsoft.com/zh-CN/magazine/ee335707.aspx

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

使用OAUth 2进行联合

在此解决方案中：

• 客户端显示由身份验证服务（通常是网页）提供的一些UI
• 用户在该UI中输入其凭据，然后身份验证服务进行身份验证，并最终将令牌返回给客户端。令牌的性质既未标准化，也未加密。通常，它将至少已签名。
• 客户端将令牌与每个请求一起提交给WCF服务。
• WCF服务像以前的解决方案一样对令牌进行身份验证

在OAuth术语中：

• 您的身份验证服务是授权服务器
• 您的WCF服务是资源所有者
• 您的客户就是客户

同样，这听起来很复杂，但是.Net对此提供了很好的支持。虽然目前可能还不如WS-Trust方法。Windows Azure AD和客户端使用Windows Azure身份验证库支持它。可能其他服务使用此方法-例如Facebook。

这在哪里很好用

• 您的客户端规格低或没有加密功能（例如浏览器或某些电话）
• 您无法控制客户端（例如，第三方应用程序正在访问您的服务）

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

它的优点是：

• 它更简单，因此具有更广泛的平台支持
• 它越来越受欢迎，因此图书馆的支持一直在不断改善
• 用户永远不会在用户界面中输入凭据，而只会在auth服务器中输入凭据，因此（在Internet场景中）它更可能被信任
• 它具有一种内置的方式来控制授予客户端的权限范围，并撤消这些权限，因此在Internet场景中它再次受到信任

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

http://msdn.microsoft.com/zh-CN/library/windowsazure/jj573266.aspx

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

http://dotnetopenauth.net/

我会说哪种方法最适合您取决于我的身份验证服务的性质。以及您是处于企业场景还是互联网场景。如果认证。可以很容易地将服务修改为WS-Trust安全令牌服务（STS），这将是一个不错的选择。如果向身份验证添加一些Web UI。服务是可行的，OAuth可能更好。

或者，如果两种方法都不可行，则可以仅采用一种方法中的模式并使用该方法而无需遵循完整的标准。

祝好运！