基于声明的身份验证- WIF：第 3 部分
本文讨论了早期方法存在的一些问题，并讨论了身份联合。
引言
这是关于基于声明的身份验证和WIF系列的第三部分。在第一部分中，我们讨论了基于声明的身份验证的基础知识，在第二部分中，我们探讨了WIF，还讨论了一个示例，并创建了一个自定义身份提供程序（IP）和ASP.NET应用程序（RP）。这个ASP.NET应用程序使用身份提供程序进行身份验证。
您可以在下面找到这两篇文章
现在，在这篇文章中，我们将讨论我们在前几篇文章中讨论的模型所面临的问题。
在我们上一个示例中，我们讨论了使用自定义身份提供程序进行身份验证的简单方法。但事情并不像我们讨论的那么简单。现在，当我们外部化身份验证系统并使用身份提供程序来验证用户时，在某些情况下，可能需要使用多个身份提供程序，如Facebook、Google、Windows Live ID等。它看起来会像这样
假设我创建了一个应用程序，并希望允许用户选择身份提供程序的选项。那么流程图将是这样的
但是，在开放的世界中，身份提供程序使用不同的协议，有些还开发了自己专有的协议，所以您的RP必须理解所有这些协议。因此，您的应用程序需要理解所有这些协议，并能够验证和读取令牌。为此，我们需要编写额外的代码来处理所有这些各种协议。现在场景会是这样
这不是一个好解决方案。如果您想为您的依赖方（Relying Party）添加一个新的身份提供程序怎么办？这意味着您需要更改应用程序的代码来适应新的身份提供程序。所以这不是一个好方法，因为您每次都需要更改RP的代码。
现在让我们来看另一个场景。在您的组织中，用户可以使用多个应用程序，并且这些应用程序信任多个身份提供程序。现在，您需要在每个应用程序中编写连接代码来处理所有这些身份提供程序。
再举一个场景，如果用户使用的身份提供程序不受应用程序信任。但是，如果有一个身份提供程序被另一个身份提供程序信任，而后者又被应用程序信任，这就称为身份联合。
以上所有场景都可以通过身份联合轻松处理，即您可以有一个身份提供程序（称为联合提供程序），它实际上首先接收（信任）来自所有各种身份提供程序的令牌，然后发出一个应用程序可以理解的通用令牌，也就是说，应用程序只信任联合提供程序。所有处理各种身份提供程序的连接代码都已移至联合提供程序。
这使得生活变得非常轻松。
现在您可以看到以上所有问题都可以轻松处理。那么，让我们来讨论一下这个过程是如何进行的。
步骤1：用户访问依赖方应用程序。
步骤2：由于用户未进行身份验证，依赖方应用程序会将用户转发到其信任的身份提供程序（在此为联合提供程序以获得身份验证）
步骤3：现在，联合提供程序本身不是一个身份提供程序，它依赖于几个其他身份提供程序。因此，它向用户提供身份提供程序的列表以进行身份验证。
步骤4：现在用户会收到一个受信任的身份提供程序列表，它选择一个身份提供程序（它拥有账户），并进行身份验证。一旦身份验证成功，选定的身份提供程序将为用户颁发一个令牌，并将其传递给联合提供程序。
步骤5：现在，由于联合提供程序信任该身份提供程序，因此它可以理解令牌。它首先验证令牌，并在需要时解密它。它验证并读取传入的令牌，然后颁发一个新令牌，并使用声明规则（如果有）将来自身份提供程序令牌的声明转换为新令牌。
步骤6：新令牌（由FP颁发）被传递到应用程序（依赖方）。
步骤7：然后，此令牌被转发到依赖方。由于依赖方信任联合提供程序，因此它可以理解令牌并进行验证，一旦验证成功，它就允许访问该应用程序。
因此，上述过程在后台进行，用户无需关心。用户只需从列出的身份提供程序中选择一个，选择并输入凭据进行身份验证。其余过程在后台进行。整个过程也称为单点登录。
因此，从上述流程中，我们了解到不仅一个依赖方信任身份提供程序，而且一个身份提供程序也可以信任另一个身份提供程序。
在上述场景中，还有两个身份提供程序参与其中。第一个提供程序将令牌连同声明发送给其他提供程序。现在，第二个提供程序可以选择转换声明，例如删除声明、添加新声明、将两个或多个声明合并为一个、将一个声明拆分为两个或多个等。这可以根据需要进行。这些类型的操作可以在联合提供程序 Windows Azure Access Control Service 中进行，该服务在此模型上运行。在此，ACS充当联合提供程序，我们在此指定一些预先指定的身份提供程序，如Facebook、Google、adfs等。我们将在我的下一篇文章中详细讨论。
历史
- 2011年11月26日：初稿