基于声明的身份验证和 WIF：第 1 部分

引言

关于基于声明的身份验证的讨论很多。在本文中，我们将了解什么是基于声明的身份验证，其好处是什么，以及更多内容。这是我这个系列的第一篇文章。在后续的文章中，我们将看到实现和更多场景。

首先，我们来了解一下为什么需要基于声明的身份验证？

当前身份验证的问题

我们在多个门户/网站上创建了多个用户账户。每次我们需要访问相应的网站时，都需要记住用户名和密码，如果某种原因我们忘记了密码，就需要记住一些特定信息，如安全问题等，才能重新访问账户。而且每次我们可能都记不住所有这些信息。另外，不建议将您的用户凭据写在物理介质上。

还有另一个问题，大多数应用程序都使用某种身份验证机制，主要是经典的用户名和密码。由于大多数开发人员并非真正的安全专家；他们在开发过程中会留下容易被破解的漏洞。因此，这是一个重大的安全风险。

大多数开发人员或多或少都曾处理过单点登录 (SingleSignOn) 功能。这并不总是一项简单的任务。在应用程序部署到 UAT/生产环境后，会导致许多挑战和问题。

作为用户，我们在互联网上的许多应用程序（如 Facebook、Yahoo、Gmail 等）以及一些内部网站（如某些大学门户网站等）或某些企业应用程序上创建新的用户凭据（用户名和密码）。因此，每次都创建新凭据，并记住所有这些凭据并确保它们足够安全，这是非常繁琐的。如果出现任何错误，您可能会丢失一些凭据，并可能导致重大损失。

解决方案

想象一下这样的情况，您只需要一个用户凭据，即用户名和密码，就足以访问您所有的门户/网站。这将是一种理想情况。可能无法完全实现，但我们正朝着这个方向前进。

但这如何实现呢？

实际上，如今，当我们创建一个具有身份验证页面的应用程序时，我们需要了解它是如何工作的。实际上，当用户登录时，会为该会话分配一个身份 (Identity)，并且该身份在整个会话中保持不变，直到用户注销或会话过期。所以，让我们来看看当前的情况。

这意味着，所有具有身份验证机制的应用程序首先会验证用户并赋予一个身份，然后用户才有权访问该应用程序。因此，如果我们能将身份验证部分从应用程序中外部化，那将非常有帮助，并且同一个身份验证应用程序可以被多个应用程序使用。我将通过图示来解释。

所以基本思想是，如果有一些应用程序负责身份验证并提供身份（称为身份提供者），而应用程序依赖于这个身份，就像我们在日常生活中一样。

上面的图片是不言自明的。

基于声明的身份验证

基于声明的身份验证也遵循相同的机制。当用户尝试访问某个应用程序时，有几个身份验证/身份提供者会被各种应用程序使用。应用程序会检查用户是否已通过身份验证，如果没有，它会将用户转发到实际进行用户身份验证的身份提供者，身份提供者会给用户一个令牌，然后将用户转发回应用程序。应用程序会验证令牌，用户就可以被允许访问该应用程序。

但在 Web 场景中并非如此简单。存在一些挑战 - 谁是身份提供者？ - 依赖方 (relying party) 需要什么数据，即身份提供者可以传输哪些数据以及以何种形式传输 - 如果有多个身份提供者。应用程序如何信任它们？

实际上，如今有很多身份提供者，如 Google、Facebook、WindowsLive Id 等等。我们甚至可以为本地应用程序开发自己的身份提供者。这也可以在云中使用。

现在，如果我正在创建一个应用程序，并且该应用程序使用某个身份提供者来验证用户，那么该应用程序必须能够理解该身份提供者的令牌，并且应用程序与身份提供者之间必须存在信任关系，以便应用程序可以信赖该身份提供者发送的令牌。

基于声明的身份验证基础

现在让我们讨论一下其中涉及的基本内容。这些主要包括身份 (Identity)、令牌 (Tokens)、声明 (Claims)、身份提供者或安全令牌服务 (Security Token Service, STS)、依赖方 (Relying Party, RP) 等。为了继续前进，我们需要理解所有这些。让我们逐一讨论。

什么是身份 (Identity)

可以说，身份是能够唯一标识任何事物的信息集合。大多数其他事物也有身份，比如您的 PC、车辆等。但在这里，我们讨论的是人。所以在数字时代，我们可以说数字身份是用于识别一个人的信息集合。

令牌 (Token) 和声明 (Claims)

当数字身份通过电线传输时，它以字节流的形式传输，这就是令牌。令牌以声明 (Claim) 的形式包含有关用户的一些信息。一个令牌可以包含多个声明，每个声明包含一些特定的信息。令牌经过数字签名，以便在接收端进行验证。所以我们可以通过图示来表示：

有时令牌可以是基于 XML 的安全断言标记语言 (SAML) 格式。但现在，应用程序使用的是一种更简单的令牌，称为简单 Web 令牌 (Simple Web Token, SWT)。这样做的优点是，我们不必传递用户凭据，还可以将用户的一些其他信息传递给应用程序。

身份提供者 (Identity Provider) 和 STS

身份提供者是这项技术中的关键，它实际上会验证用户，并根据要求创建带有声明的令牌，然后在发送前进行数字签名。身份提供者也称为安全令牌服务 (Security Token Service)。STS 是如何工作的，让我们看一下。

RP (依赖方)

依赖方是使用这些身份提供者进行身份验证的应用程序。它们只需要理解和验证令牌，并从令牌本身获取所需的所有数据。但在所有这一切之前，RP 需要建立信任关系，并告知身份提供者用户需要哪些数据。这样，下次它收到令牌时，就可以验证颁发者并获取所需的数据。

完整场景

现在大家已经了解了基于声明的身份验证的所有基本信息。现在让我们来看看这个身份提供者是如何使用的。

这就是基于声明的身份验证的基础。在我的下一篇文章中，我们将借助 Windows Identity Foundation (WIF) 来关注实现部分。

请分享您对这篇文章的看法，并告诉我是否遗漏了什么。

历史

• 2011 年 10 月 13 日：初始帖子