代码改变世界

（翻译）《介绍 GENEVA Beta 1 白皮书》（3）

2009-06-03 19:31  G yc {Son of VB.NET}  阅读(600)  评论(3)  编辑  收藏  举报

有任何问题，可以查看 翻译预告 《介绍 GENEVA Beta 1 白皮书》或者直接在这里回复。

A CLOSER LOOK AT THE “GENEVA” TECHNOLOGIES
近看“Geneva” 技术

 

了解如何应用基于声明的标识（Claims-Based Identity）是很重要的。也对理解这种思想下的软件技术有所帮助。对于Windows 平台，这意味着 了解 “Geneva”服务器，CardSpace “Geneva”，和“Geneva” Framework。 本节将走进他们看看。

 

THE “GENEVA” SERVER
“Geneva”服务器

 

虽然“Geneva” 服务器比起前身 AD FS 添加了很多功能，包括 完全的（Full-fledged ） STS ，也支持先前版本的全部功能。例如，之前说的，“Geneva”服务器允许使用 WS-Federation 来为被动（Passive）客户端（如，Web浏览器）提供 联合标识验证（Federation Identity）。然而，不像 ADFS，“Geneva”服务器也支持使用SAML 2.0 协议来完成这个，就像先前说的一样。支持这个 替代性（alternative）协议， 该协议也得到了 自由联盟（Liberty Alliance）和其他方的拥护，使得 带有“Geneva”服务器 的系统能够与更多的 联合标识（Identity Federation ）产品一同工作。

另外，也像 ADFS，“Geneva”服务器 允许管理员去和其它的STS建立信任。图13 说明了如何工作的原理。

clip_image001

图13：要在STS间建立信任关系，需要交换证书和其他东西。

这个图中的情形和先前的图11中的相同：在企业Y中的应用程序只信任自己的STS发布的令牌（Token）。这意味着，在企业X的客户端必须先从自己的STS上获得令牌（Token），然后使用这个令牌（Token）来向在企业Y中的STS请求新的令牌（Token），和之前描述的一样。要完成这个，需要解决几个问题。

例如，如何做才能让在企业Y中的 STS （被称作联合提供程序（Federation Provider））知道客户端实际发送的令牌（Token）是由企业X中的 STS （标识提供程序（Identity Provider））颁发的？ 答案就是标识提供程序（Identity Provider） 使用自己的私有签名密钥对这个令牌（Token）进行了 签名。 为了让 联合提供程序（Federation Provider）可以来验证这个签名，标识提供程序（Identity Provider） 会发送一个证书，其中包含了与这个签名密钥相对的公钥，如图13 所示的。 同样，联合提供程序（Federation Provider） 也能够转换接收到的令牌（Token），根据管理员定义的转换策略（Transformation policy）。要定义这个策略，联合提供程序（Federation Provider） 必须拥有 标识提供程序（Identity Provider）可能发送给它的所有可能的声明类型（Claim Type）列表。 如 图13 中， 标识提供程序（Identity Provider）向 联合提供程序（Federation Provider）发送它可能会接收到的声明类型（Claim Type）列表。

这里还有另一个问题：当标识提供程序（Identity Provider） 为 联合提供程序（Federation Provider）创建令牌（Token）的时候，它可以加密这个令牌（Token），使攻击者无法读取。要做到这个，联合提供程序（Federation Provider）向 标识提供程序（Identity Provider）发送一个包含加密密钥的证书，如图13所示。标识提供程序（Identity Provider）使用这个证书中的公钥来加密所有发送给 联合提供程序（Federation Provider）的令牌（Token），确保仅有 联合提供程序（Federation Provider）才能读取它们。

ADFS 也需要类似的交换来建立 联合域（Federated Domains） 之间的信任。 “Geneva” 服务器 通过自动化那些在ADFS中完全手动的过程来使这个过程变的简单。例如，当证书即将到期的时候，“Geneva”服务器能自动的创建一个新的密钥对和证书，然后发送证书到合作伙伴的STS上。

“Geneva”服务器 另一个改进是提供了比ADFS更广泛的储存标识信息（Identity Information） 的支持。 不像其前身，“Geneva” 服务器认为储存账户 是应该包含像 用户名和密码和分离的用于储存其他用户信息属性（Attribute）的储存。 对于账户储存，“Geneva”服务器支持 ADDS或 ADLDS。对于属性（Attribute）储存，微软计划在最终版中支持大量可选项，包括 AD DS， AD LDS ， SQL Server 等（虽然在第一个Beta版中，无法用到全部）。

 

CARDSPACE “GENEVA”

 

CardSpace “Geneva” 是 微软的CardSpace技术的第二个版本。原理和之前的一样，并增强了 CardSpace 的设计者们在第一次发布之后学到的东西。本节将深入了解这个技术如何工作，包括 CardSpace “Geneva” 中的一些重大改变。

 

信息卡（Information Cards）

 

CardSpace “Geneva” 给用提供了一种使用卡片（Card）来表示每个可用的标识（Identity），如先前图6中显示的那样。当用户选择一个卡片（Card）的时候，CardSpace “Geneva” 向其对应的 标识提供程序（Identity Provider）的STS发送 令牌（Token）请求。但是如何在用户看到的卡片和对应的STS 建立联系？答案就是：在每个卡片和标识提供程序（Identity Provider）之间的关系是由某个STS发布的信息卡（Information Card）来表示的。图14 显示了它的样子。

clip_image001[12]

Figure 14: Each information card is associated with a particular digital identity at some identity provider.

图14： 每个信息卡（Information Card） 关联了一个在某个标识提供程序（Identity Provider）的一个特定数字标识（Digital Identity）。

信息卡（Information Card） 仅仅是一个XML文件，如图所示，每个信息卡（Information Card） 由一个和标识提供程序（Identity Provider）的关系构成。这个关系可以让用户从标识提供程序（Identity Provider）获得使用的令牌（Token），并且应用程序将会接受这些令牌（Token）。信息卡（Information Card）包含了任何需要用来寻找正确的STS和正确的标识提供程序（Identity Provider）的所有信息，然后为这个卡片（Card）所表示的标识（Identity）请求令牌（Token）。但是，卡片（Card）中不包含任何声明（Claims），这全部由 标识提供程序（Identity Provider） 来维护。 信息卡（Information Card） 的唯一作用是储存用来查找正确STS的信息和为所表示的标识（Identity）请求令牌（Token）。

术语可能让你感到困惑，所以这里简要的概括一下：一个用户选择一个卡片（Card）（一种可见的表示）就是一个信息卡（Information Card）（一个XML文件），它包含了用于请求令牌（Token）（一个由STS发布的签名过的一组字节）的全部信息。 不要混淆信息卡（Information Card） 和令牌（Token）——它们不是同一个东西。

下一个问题：因为用户的标识（Identity）是由储存在用户的机器上的信息卡（Information Card）所表示的，那么信息卡（Information Card）是怎样到用户的机器上呢？答案是取决于发布信息卡（Information Card）的STS。 信息卡（Information Card）不包含机密信息——如，信息卡（Information Card）中没有保存用于向STS请求令牌（Token）时来认证用户的密码——所以这个问题没有多少挑战。“Geneva” 服务器 可以通过多种方式安装 信息卡（Information Card） 到用户的机器上，其他供应商的STS也可以做到，如IBM's Tivoli Federated Identity Manager。 类似的，其他的 身份选择器（Identity Selector） 也支持 信息卡（Information Card），如开源的 Higgins选择器（Higgins Selector），也可以来至 “Geneva” Server 和其它STS的卡片。

另一个挑战是：让基于信息卡的标识（Information Card-based Identity）支持用户漫游。 我们之中的很多人都会在公司使用一台桌面计算机工作，在家里使用另一个台，然后出门在外使用笔记本电脑，然而，我们想要在这些机器中使用同一个 数字标识（Digital Identity）。为了让用户可以在这几个不同的机器间漫游，CardSpace 提供一个 卡片（Card） 到处功能。这个功能允许复制 信息卡（Information Card） 到外部储存介质，如USB Key。 然后这些卡片（Card）就可以被安装到其他机器上，让用户使用一致的方式向 标识提供程序（Identity Provider） 请求安全令牌（Security Token），无论是在使用他的家中的电脑，办公室的电脑，还是他在旅馆房间中的笔记本电脑。为了防止攻击，导出的 信息卡（Information Card） 是使用用户选择的（User-Selected）密码短语（ Pass-Phrase）来密钥加密的。这个确保了即使储存介质丢失，只有知道正确密码短语（Pass-Phrase）的人才能解密卡中的内容。微软也尝试调查让用户存储 信息卡（Information Card）在互联网可以访问的服务器上（如，储存在云中）的可能性。当你控制了一个机器，然后 CardSpace “Geneva”能够连接到这些不可见的基于云的信息卡（Cloud-Based Information Card），并使用它们请求令牌（Token）。这使得我们使用的每个机器上共享标识（Identities）变得更简单。

还有另一个 CardSpace “Geneva” 必须解决的问题就是 吊销（Revocation）。一旦 标识提供程序（Identity Provider） 给一个用户颁发了一个信息卡（Information Card），如何才能吊销那张卡片（Card）？在最简单的情况下，标识提供程序（Identity Provider）自己可以决定希望停止发布对这个卡片（Card）的 安全令牌（Security Tokens）。 如，也许使用这个令牌是需要付费订阅的，然而用户却没有继续预付费用。 吊销（Revocation）在这种情况下很简单： 标识提供程序（Identity Provider）仅仅停止了 对这个卡片的安全令牌（Security Token）请求。每个请求中包含CardSpace的唯一引用，所以标识提供程序（Identity Provider）可以方便的识别出使用已注销的（Revoked）卡片发出的请求。

稍微在复杂一点的情况是用户希望注销（Revoke）一个信息卡（Information Card）。可能攻击者偷走了用户的笔记本电脑，其中包含了各种 标识提供程序（Identity Provider）发布的 信息卡（Information Card）。 要解决这个问题， 需要给每个 信息卡（Information Card）分配一个PIN ，并在每次使用卡片的时候输入。如果做到了这点，攻击者将不能使用盗窃的卡片（Card）（因此，也就不能使用对应的 标识（Identities）），除非用户知道每个卡片的PIN。 另外， 还记得在使用外部的 标识提供程序（Identity Provider） 颁发的卡片时，通常会要求用户来证明自己的身份，如通过输入密码。由于这个验证信息（Authentication Information） 没有包含到 卡片（Card）中，所以攻击者不能使用这些偷窃过来的卡片（Card）来伪装成用户。

要使身份选择器（Identity Selector）变得有用武之地的方法是让信息卡（Information Card）变得无处不在。为了帮助用户明确的知道当前网站接受 基于信息卡的登录（Information Card-based Logins），而制作出来的标准图标显示在图15中。 一个声明意识（Claims-aware）的应用程序，无论是由 “Geneva” Framework 或者其他方法构建的，都可以显示这个图标来让用户知道他们可以使用基于卡片的登录（Card-based Logins）。 还有信息卡基金会（Information Card Foundation） 致力于这一技术的发展。基金会的董事会成员包括一系列的组织，包括的Equifax ，谷歌，微软， Novell ，甲骨文，和PayPal 。 自由联盟（Liberty Alliance）（另一个重要的标识（Identity）组织）也是基金会的创建成员之一。

clip_image002

图15：一个网页可以显示这个 图标 来 指示这个网站接受 基于信息卡的登录（Information Card-based Logins）

 

自颁发标识提供程序（The Self-Issued Identity Provider）

 

在前面的例子中，标识提供程序（Identity Provider）和STS 一直在用户的机器的外部。但是，没有理由说明这个为什么是正确的。为什么用户不能自己作为自己的 标识提供程序（Identity Provider），向安装到她自己机器上的STS请求令牌（Tokens）？ 答案是肯定的，她可以使用 CardSpace “Geneva” 的 自颁发标识提供程序（Self-Issued Identity Provider） 功能。图16 说明了这个想法。

clip_image001[14]

图16：自颁发标识提供程序（Self-Issued Identity Provider）允许用户去担当她自己的 标识提供程序（Identity Provider）。

使用 自颁发标识提供程序（Self-Issued Identity Provider） 改变了一些事情，比如有多少应用程序可以使用这个提供程序颁发的声明（Claims），但过程还是完全一样的。如图所示，自颁发标识提供程序（Self-Issued Identity Provider），包含了完整的STS，并运行在用户的电脑上。和其他的 标识提供程序（Identity Provider）一样，用户可以安装信息卡（Information Card），并且它关联了这个自颁发标识提供程序（Self-Issued Identity Provider）维护的 标识（Identity）。 当用户选择的卡片（Card）关联的是这个标识（Identity）的时候，CardSpace “Geneva” 的身份选择器（Identity Selector）会向 本地的 自颁发标识提供程序（Self-Issued Identity Provider）请求SAML令牌（Token），然后发送这个令牌（Token）到任何用户访问的程序。令牌（Token）中的声明（Claims）是固定的——用户不能添加它们——并且它们只包含基本信息，像是用户的名字。

然而这里有个显而易见的问题：这些令牌（Token）的好处是什么？ 当应用程序获得一个外部标识提供程序（Identity Provider） 发布的令牌（Token）的时候，它能够信任令牌（Token）中包含的声明（Claims）（当然，假设它信任这个 标识提供程序（Identity Provider））。但是如何能让应用程序总是信任来自用户自己的 标识提供程序（Identity Provider） 的声明（Claims）？

要知道 自颁发标识（Self-Issued Identity）什么时候会有用，想想看 用户名和密码 在如今的互联网上是多么的常见。当你访问一个新的网站的时候，你通常会被要求创建一个用户名和密码，然后它们被储存在那个网站上。下次你访问这个站点的时候，你会提供同样的用户名和密码，好让网站认出你。但是，网站真的知道你是谁吗？当然不知道。选择用户名是“Angelina Jolie（安吉丽娜·朱莉）” 并不意味着你就是那个注明的影星。 用户名和密码的真正目的不是去确定你真实的身份（Identity）。它是用来让网站每次作为同一个作为同一个用户认出你来，证明了连续性的关系。

自颁发标识提供程序（Self-Issued Identity Provider）创建的令牌（Token）可以用同样的方式使用。虽然 应用程序接受这些令牌（Token）不会很信任这个令牌（Token）中包含的声明（Claims）（就像自己选择的（Self-Chosen）用户名一样），它是用来每次作为同一个用户认出你。对于现今许多应用，包括几乎所有的网站都是依赖用户名和密码的，这就是它们所需要的。

但是为什么？ CardSpace “Geneva” 自颁发标识提供程序（The Self-Issued Identity Provider） 颁发的令牌（Token）比 简单的用户名和密码的好处是什么？ 除非比如今的用户名和密码有些优势，否者我们没有理由来改变。 但是，这些令牌（Token）确实有很大好处，包括如下：

  • 和密码不同， 自颁发标识提供程序（The Self-Issued Identity Provider） 创建的 SAML 令牌（Token） 包含复杂的加密，能使除了真正的主人以外都不能使用它。由于这些令牌（Token）不能被盗取和重用，所以钓鱼问题将得到很大改善。
  • 与其让用户输入基本的个人信息，不如让令牌（Token）自动的提供这些数据。强制的让用户进行某种注册过程是让用户放弃继续访问网站的主要原因之一，所以这样做可以让网站更加便于使用。
  • 自颁发标识提供程序（The Self-Issued Identity Provider） 的令牌（Token） 可以仅仅通过公钥来验证。由于公钥不需要保密，应用程序可以接受 自颁发的令牌（Self-Issued Token） 而不用担心它们被盗取。

 

在基于声明的标识（Claims-Based Identity） 的术语中，来至 自颁发提供程序（Self-Issued Provider） 的 信息卡（Information Card）被称作 个人卡（Personal Card）， 来至外部标识提供程序（Identity Provider）颁发的 信息卡（Information Card）被叫做 托管卡（Managed Card）。 就像应用程序可以指出可以接受哪些外部 标识提供程序（Identity Provider）的令牌（Token）一样，也可以指出是否接受 自颁发提供程序（Self-Issued Provider）的令牌（Token）。（还有重要的一点需要指出： 自颁发提供程序（Self-Issued Provider） 没有包含在 CardSpace “Geneva”第一个Beta 1发行版中。）

在结束这个 CardSpace 讨论之前， 列出那些在CardSpace “Geneva” 中比较重要的更改。 其一是现在 CardSpace “Geneva” 可以从 .NET Framework 中分离出来，使其更小，速度更快。新版本还对用户反复访问的应用程序做了优化。例如，当你再次访问一个网站的时候，可以直接在页面中显示你最后一次用于登录站点时选择的卡片——CardSpace “Geneva” 屏幕不会出现。在某些情况，用户可以在 CardSpace “Geneva” 选择屏幕中通过勾选一个选项框来反复使用指定的标识（Identity）。此外，微软也在调查让企业的管理员推送策略到桌面，那个策略指定了访问某个网站时应该用什么标识（Identity）。如果这个成功，这些标识（identity）就可以直接使用，用户不再看到 CardSpace “Geneva” 选择器屏幕了。

“Geneva”Framework

 

STS提供的令牌（Token）包含 标识（Identity）信息， 身份选择器（Identity Selector）可以帮助选择他们选择想要使用的令牌（Token）。除非修改应用程序可以接受和使用这些令牌（Token），否则它们是没有用的。“Geneva” Framework 的目标是使做这个变得更简单，帮助开发者创建声明意识（Claims-aware）的应用程序。

例如，先前描述的，“Geneva” Framework 提供对于验证令牌（Token）的签名和提取声明（Claim） 的构建支持（Built-support）。每个提取出来的声明（Claim） 被封装到 “Geneva” Framework 定义的 Claim 类的实例中，为开发者提供了一致的方式来使用令牌（Token）的信息。这个类包含了以下属性：

  • ClaimType，指出这个声明（Claim）的类型。例如，声明（Claim）中是否包含用户的名字，或者角色，或者其他什么东西？ 声明（Claim）类型通过典型的URI字符串来识别出来。
  • Value，声明（Claim）中包含的实际内容，如用户的名字。
  • Issuer，指出这个声明（Claim）来至哪个 标识提供程序（Identity Provider）。换句话说，这个实体 断言了这个声明（Claim） 是真实的。

 

除了帮助开发者创建 声明意识（Claims-aware）的应用程序外，“Geneva” 框架也提供了对创建自定义的STS支持。虽然 “Geneva” 服务器的主要目标就是减少你制作自己的STS，但是有些情况下建立自己的STS是可以理解的。例如，独立软件开发商（ISV）可以使用“Geneva”Framework 去创建自定义的STS 来达到自己的目的。

“Geneva” Framework 中还有更多东西，声明意识（Claims-aware）的 Windows应用程序将会喜欢这个类库（“Geneva” Framework）。关于这个技术的更多详细信息和使用方法可以查看 Keith Brow 的白皮书 ，在 https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=642&DownloadID=12901。

 

CONCLUSIONS
总结

 

改变人是和应用程序使用标识（Identity）的方式不是一件小事。鉴于于此，普遍的使用 基于声明的标识（Claims-Based Identity） 还需要一些时间。不过，基金会正在致力于这方面的更多实质性的改善。

随着 “Geneva” 服务器的出现，CardSpace “Geneva” 和“Geneva” Framework的出现， 所有的这些都是用在 Windows 上的 基于声明的标识（Claims-Based Identity） 。虽然这种与表示（Identity）的工作方式是微软主导的，并使这些组件在更多 Windows 上受欢迎。对于任何关心改善在数字世界中使用标识（Identity）方式的人，这是坚实的迈出一步。

 

ABOUT THE AUTHOR
关于作者

 

David Chappell 是加利福尼亚州旧金山 Chappell & Associates (www.davidchappell.com) 的负责人。他通过讲演、撰稿和咨询，帮助全球的技术专业人员了解和使用企业软件，并制定更佳的决策。