A CLOSER LOOK AT THE “GENEVA” TECHNOLOGIES
近看“Geneva” 技术
有任何问题，可以查看 翻译预告 《介绍 GENEVA Beta 1 白皮书》或者直接在这里回复。
A CLOSER LOOK AT THE “GENEVA” TECHNOLOGIES
近看“Geneva” 技术
了解如何应用基于声明的标识（Claims-Based Identity）是很重要的。也对理解这种思想下的软件技术有所帮助。对于Windows 平台，这意味着 了解 “Geneva”服务器，CardSpace “Geneva”，和“Geneva” Framework。 本节将走进他们看看。
THE “GENEVA” SERVER
“Geneva”服务器
While the “Geneva” Server adds quite a bit to its predecessor AD FS, including a full-fledged STS, it also supports all of the functions of its earlier incarnation. For example, as mentioned earlier, the “Geneva” Server allows using WS-Federation to provide identity federation for passive clients (i.e., Web browsers). Unlike AD FS, however, the “Geneva” Server also supports using the SAML 2.0 protocol for this purpose, as mentioned earlier. Supporting this alternative protocol, which has been embraced by the Liberty Alliance and others, allows Windows systems with the “Geneva” Server to work with a broader range of identity federation products.
虽然“Geneva” 服务器比起前身 AD FS 添加了很多功能，包括 完全的（Full-fledged ） STS ，也支持先前版本的全部功能。例如，之前说的，“Geneva”服务器允许使用 WS-Federation 来为被动（Passive）客户端（如，Web浏览器）提供 联合标识验证（Federation Identity）。然而，不像 ADFS，“Geneva”服务器也支持使用SAML 2.0 协议来完成这个，就像先前说的一样。支持这个 替代性（alternative）协议， 该协议也得到了 自由联盟（Liberty Alliance）和其他方的拥护，使得 带有“Geneva”服务器 的系统能够与更多的 联合标识（Identity Federation ）产品一同工作。
Also like AD FS, the “Geneva” Server allows an administrator to establish trust with other STSs. Figure 13 illustrates the fundamentals of how this works.
另外，也像 ADFS，“Geneva”服务器 允许管理员去和其它的STS建立信任。图13 说明了如何工作的原理。
Figure 13: Establishing a trust relationship between STSs requires exchanging certificates and more.
图13：要在STS间建立信任关系，需要交换证书和其他东西。
The situation shown here is identical to the one shown earlier in Figure 11: The application in enterprise Y only trusts tokens issued by its own STS. This means that a client in enterprise X must first get a token from its own STS, then use this to request a new token from the STS in enterprise Y, as described earlier. Accomplishing this requires addressing several issues.
这个图中的情形和先前的图11中的相同：在企业Y中的应用程序只信任自己的STS发布的令牌（Token）。这意味着，在企业X的客户端必须先从自己的STS上获得令牌（Token），然后使用这个令牌（Token）来向在企业Y中的STS请求新的令牌（Token），和之前描述的一样。要完成这个，需要解决几个问题。
For example, how does the STS in enterprise Y, called the federation provider, know that the token this client sends was actually issued by the STS in enterprise X, referred to as the identity provider? The answer is that this token is signed by the identity provider using its private signing key. To allow the federation provider to verify this signature, the identity provider sends it a certificate containing the corresponding public key for this signing key, as Figure 13 shows. Also, the federation provider is able to transform tokens it receives based on a transformation policy defined by its administrator. To define this policy, the federation provider must have a list of every possible claim type that the identity provider might send to it. As Figure 13 shows, the identity provider sends the federation provider a list of the claim types it can expect to receive.
例如，如何做才能让在企业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）列表。
Here’s another problem: When the identity provider creates a token that’s destined for the federation provider, it can encrypt this token so attackers can’t read it. To allow this, the federation provider sends a certificate for its encryption key to the identity provider, as Figure 13 shows. The identity provider uses the public key in this certificate to encrypt all tokens it sends to this federation provider, ensuring that only the federation provider’s STS can read them.
这里还有另一个问题：当标识提供程序（Identity Provider） 为 联合提供程序（Federation Provider）创建令牌（Token）的时候，它可以加密这个令牌（Token），使攻击者无法读取。要做到这个，联合提供程序（Federation Provider）向 标识提供程序（Identity Provider）发送一个包含加密密钥的证书，如图13所示。标识提供程序（Identity Provider）使用这个证书中的公钥来加密所有发送给 联合提供程序（Federation Provider）的令牌（Token），确保仅有 联合提供程序（Federation Provider）才能读取它们。
AD FS required similar exchanges to establish trust between federated domains. The “Geneva” Server makes this process simpler by automating what were entirely manual processes in AD FS. For example, when a certificate is about to expire, the “Geneva” Server can automatically create a new key pair and certificate, then send the certificate to its partner STS.
ADFS 也需要类似的交换来建立 联合域（Federated Domains） 之间的信任。 “Geneva” 服务器 通过自动化那些在ADFS中完全手动的过程来使这个过程变的简单。例如，当证书即将到期的时候，“Geneva”服务器能自动的创建一个新的密钥对和证书，然后发送证书到合作伙伴的STS上。
Another advance that the “Geneva” Server provides over AD FS is broader support for storing identity information. Unlike its predecessor, the “Geneva” Server views its account store, containing things like usernames and passwords, separately from its attribute store, which holds other information about users. For the account store, the “Geneva” Server supports either AD DS or AD LDS. For the attribute store, Microsoft plans to allow a range of options in the final release, including AD DS, AD LDS, SQL Server, and others (although not all of these are available in the first beta release).
“Geneva”服务器 另一个改进是提供了比ADFS更广泛的储存标识信息（Identity Information） 的支持。 不像其前身，“Geneva” 服务器认为储存账户 是应该包含像 用户名和密码和分离的用于储存其他用户信息属性（Attribute）的储存。 对于账户储存，“Geneva”服务器支持 ADDS或 ADLDS。对于属性（Attribute）储存，微软计划在最终版中支持大量可选项，包括 AD DS， AD LDS ， SQL Server 等（虽然在第一个Beta版中，无法用到全部）。
CARDSPACE “GENEVA”
CardSpace “Geneva” is the second version of Microsoft’s CardSpace technology. The basics are the same as in the original, with enhancements that reflect what CardSpace’s designers have learned since its first release. This section takes a deeper look at how this technology works, including some of the most important changes in CardSpace “Geneva”.
CardSpace “Geneva” 是 微软的CardSpace技术的第二个版本。原理和之前的一样，并增强了 CardSpace 的设计者们在第一次发布之后学到的东西。本节将深入了解这个技术如何工作，包括 CardSpace “Geneva” 中的一些重大改变。
信息卡（Information Cards）
To a user, CardSpace “Geneva” represents each available identity as a card, as shown earlier in Figure 6. When a user selects a card, CardSpace “Geneva” requests a token from an STS at the corresponding identity provider. But how is the connection made between the card seen by a user and this STS? The answer is that each association between a card and an identity provided by some STS is represented by an information card. Figure 14 shows how this looks.
CardSpace “Geneva” 给用提供了一种使用卡片（Card）来表示每个可用的标识（Identity），如先前图6中显示的那样。当用户选择一个卡片（Card）的时候，CardSpace “Geneva” 向其对应的 标识提供程序（Identity Provider）的STS发送 令牌（Token）请求。但是如何在用户看到的卡片和对应的STS 建立联系？答案就是：在每个卡片和标识提供程序（Identity Provider）之间的关系是由某个STS发布的信息卡（Information Card）来表示的。图14 显示了它的样子。
![clip_image001[12]](https://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/GENEVABeta13_106/clip_image001%5B12%5D_thumb.png "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）。
An information card is just an XML file, and as the figure shows, each one represents a relationship with an identity provider. This relationship lets the user get tokens from the identity provider for use with applications willing to accept these tokens. The information card contains everything needed to find the right STS at the right identity provider, then request a token for the identity this card represents. The card doesn’t contain any claims, however; these are all maintained by the identity provider. The sole purpose of the information card is to store the information needed to find the right STS and request a token for a particular 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）。
The terminology can get confusing, so here’s a quick recap: A user selects a card (a visual representation) that’s associated with an information card (an XML file) that contains all of the information needed to request a token (a signed group of bytes issued by an STS). Don’t confuse information cards with tokens—they’re not the same thing.
术语可能让你感到困惑，所以这里简要的概括一下：一个用户选择一个卡片（Card）（一种可见的表示）就是一个信息卡（Information Card）（一个XML文件），它包含了用于请求令牌（Token）（一个由STS发布的签名过的一组字节）的全部信息。 不要混淆信息卡（Information Card） 和令牌（Token）——它们不是同一个东西。
Next question: Since every identity a user has is represented by an information card stored on the user’s machine, how do the information cards get there? The answer is that it’s up to the STS. Information cards don’t contain confidential information—they don’t hold a password the user supplies to authenticate token requests to the STS, for instance—so the problem isn’t too challenging. The “Geneva” Server can install an information card on a user’s machine in various ways, as can STSs from other vendors, such as IBM’s Tivoli Federated Identity Manager. Similarly, other identity selectors that support information cards, such as the open source Higgins selector, can accept cards provided by the “Geneva” Server and other STSs.
下一个问题：因为用户的标识（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的卡片。
Another challenge for information card-based identity is supporting roaming users. Many of us use a desktop computer at work, another one at home, and a laptop while we’re traveling, yet we’d like to present the same digital identity from all of them. To allow a user to roam among these different machines, CardSpace provides a card export feature. This option allows copying information cards onto an external storage medium, such as a USB key. The cards can then be installed onto other machines, letting a user request security tokens from identity providers in the same way whether he’s using his home computer, his office computer, or his laptop in a hotel room. To guard against attacks, exported information cards are encrypted using a key derived from a user-selected pass-phrase. This ensures that even if the storage medium is lost, only someone who knows the pass-phrase can decrypt the cards it contains. Microsoft is also investigating the possibility of letting a user store information cards on an Internet-accessible server, i.e., in the cloud. On a machine you control, CardSpace “Geneva” could then connect invisibly to these cloud-based information cards, using them to request tokens. This would make it easier to share identities among the small set of machines that each of us use regularly.
另一个挑战是：让基于信息卡的标识（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）变得更简单。
Yet another issue that CardSpace “Geneva” must address is revocation. Once an identity provider has issued an information card to a user, how can that card be revoked? In the simplest case, the identity provider itself might wish to stop issuing security tokens based on this card. Perhaps using this identity provider requires a paid subscription, for example, and the user hasn’t kept up his payments. Revocation in this case is simple: the identity provider just stops honoring requests for security tokens made with this card. Every request carries a unique CardSpace reference, so it’s easy for the identity provider to identify requests made with cards it has revoked.
还有另一个 CardSpace “Geneva” 必须解决的问题就是 吊销（Revocation）。一旦 标识提供程序（Identity Provider） 给一个用户颁发了一个信息卡（Information Card），如何才能吊销那张卡片（Card）？在最简单的情况下，标识提供程序（Identity Provider）自己可以决定希望停止发布对这个卡片（Card）的 安全令牌（Security Tokens）。 如，也许使用这个令牌是需要付费订阅的，然而用户却没有继续预付费用。 吊销（Revocation）在这种情况下很简单： 标识提供程序（Identity Provider）仅仅停止了 对这个卡片的安全令牌（Security Token）请求。每个请求中包含CardSpace的唯一引用，所以标识提供程序（Identity Provider）可以方便的识别出使用已注销的（Revoked）卡片发出的请求。
A slightly more complex case is when the user wishes to revoke an information card. Perhaps an attacker has stolen the user’s laptop containing information cards issued by various identity providers. To address this problem, each information card can be assigned a PIN that must be entered each time the card is used. If this is done, an attacker can’t use the stolen cards (and thus the identities they correspond to) unless he knows the PIN for each one. Also, recall that using a card issued by an external identity provider typically requires the user to authenticate himself, such as by entering a password. Since this authentication information isn’t contained in the card itself, an attacker can’t use these stolen cards to impersonate the user.
稍微在复杂一点的情况是用户希望注销（Revoke）一个信息卡（Information Card）。可能攻击者偷走了用户的笔记本电脑，其中包含了各种 标识提供程序（Identity Provider）发布的 信息卡（Information Card）。 要解决这个问题， 需要给每个 信息卡（Information Card）分配一个PIN ，并在每次使用卡片的时候输入。如果做到了这点，攻击者将不能使用盗窃的卡片（Card）（因此，也就不能使用对应的 标识（Identities）），除非用户知道每个卡片的PIN。 另外， 还记得在使用外部的 标识提供程序（Identity Provider） 颁发的卡片时，通常会要求用户来证明自己的身份，如通过输入密码。由于这个验证信息（Authentication Information） 没有包含到 卡片（Card）中，所以攻击者不能使用这些偷窃过来的卡片（Card）来伪装成用户。
A slightly more complex case is when the user wishes to revoke an information card. Perhaps an attacker has stolen the user’s laptop containing information cards issued by various identity providers. To address this problem, each information card can be assigned a PIN that must be entered each time the card is used. If this is done, an attacker can’t use the stolen cards (and thus the identities they correspond to) unless he knows the PIN for each one. Also, recall that using a card issued by an external identity provider typically requires the user to authenticate himself, such as by entering a password. Since this authentication information isn’t contained in the card itself, an attacker can’t use these stolen cards to impersonate the user.
要使身份选择器（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）组织）也是基金会的创建成员之一。
Figure 15: A Web page can display this icon to indicate that it accepts information card-based logins
图15：一个网页可以显示这个 图标 来 指示这个网站接受 基于信息卡的登录（Information Card-based Logins）
自颁发标识提供程序（The Self-Issued Identity Provider）
In the examples described so far, an identity provider and the STS it provides have always been external to the user’s machine. There’s no reason why this has to be true, however. Why can’t the user act as her own identity provider, requesting tokens from an STS installed on her own machine? The answer is that, by using the self-issued identity provider that’s part of CardSpace “Geneva”, she can. Figure 16 illustrates this idea.
在前面的例子中，标识提供程序（Identity Provider）和STS 一直在用户的机器的外部。但是，没有理由说明这个为什么是正确的。为什么用户不能自己作为自己的 标识提供程序（Identity Provider），向安装到她自己机器上的STS请求令牌（Tokens）？ 答案是肯定的，她可以使用 CardSpace “Geneva” 的 自颁发标识提供程序（Self-Issued Identity Provider） 功能。图16 说明了这个想法。
![clip_image001[14]](https://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/GENEVABeta13_106/clip_image001%5B14%5D_thumb.png "clip_image001[14]")
Figure 16: The self-issued identity provider allows a user to act as her own identity provider.
图16：自颁发标识提供程序（Self-Issued Identity Provider）允许用户去担当她自己的 标识提供程序（Identity Provider）。
Using the self-issued identity provider changes a number of things, such as how much trust an application can place in the claims this provider issues, but the mechanics remain much the same. As the figure shows, the self-issued identity provider, complete with an STS, runs on the user’s computer. As with any other identity provider, the user can install an information card that’s associated with an identity this provider maintains. When the user selects the card associated with this identity, the CardSpace “Geneva” identity selector requests a SAML token from the local self-issued identity provider, then sends that token to whatever application the user is accessing. The claims in this token are fixed—users can’t add to them—and they include basic information such as the user’s name.
使用 自颁发标识提供程序（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）是固定的——用户不能添加它们——并且它们只包含基本信息，像是用户的名字。
Yet there’s an obvious question here: What good are these tokens? When an application gets a token issued by an external identity provider, it can have some faith in the claims that token contains (assuming it trusts the identity provider, of course). But how can an application ever trust claims that come from an identity provider owned by the user herself?
然而这里有个显而易见的问题：这些令牌（Token）的好处是什么？ 当应用程序获得一个外部标识提供程序（Identity Provider） 发布的令牌（Token）的时候，它能够信任令牌（Token）中包含的声明（Claims）（当然，假设它信任这个 标识提供程序（Identity Provider））。但是如何能让应用程序总是信任来自用户自己的 标识提供程序（Identity Provider） 的声明（Claims）？
To understand when self-issued identities can be useful, think about how usernames and passwords are commonly used on the Internet today. When you access a new site, you’re typically asked to create a username and password, which are then stored by that site. The next time you access the site, you provide the same username and password, allowing the site to recognize you. But does the site really know who you are? Of course not. Choosing the username “Angelina Jolie” doesn’t mean that you’re in fact a famous movie star. The real purpose of a username and password isn’t to establish your true identity. It’s to allow the site to recognize you as the same user each time, proving the continuity of the relationship.
要知道 自颁发标识（Self-Issued Identity）什么时候会有用，想想看 用户名和密码 在如今的互联网上是多么的常见。当你访问一个新的网站的时候，你通常会被要求创建一个用户名和密码，然后它们被储存在那个网站上。下次你访问这个站点的时候，你会提供同样的用户名和密码，好让网站认出你。但是，网站真的知道你是谁吗？当然不知道。选择用户名是“Angelina Jolie（安吉丽娜·朱莉）” 并不意味着你就是那个注明的影星。 用户名和密码的真正目的不是去确定你真实的身份（Identity）。它是用来让网站每次作为同一个作为同一个用户认出你来，证明了连续性的关系。
A token created by a self-issued identity provider can be used in the same way. While an application that accepts these tokens can’t put much faith in the claims this token contains (just as with a self-chosen username), it can recognize you as the same user over and over. For many applications, including pretty much every Web site that relies on usernames and passwords today, this is all that’s needed.
自颁发标识提供程序（Self-Issued Identity Provider）创建的令牌（Token）可以用同样的方式使用。虽然 应用程序接受这些令牌（Token）不会很信任这个令牌（Token）中包含的声明（Claims）（就像自己选择的（Self-Chosen）用户名一样），它是用来每次作为同一个用户认出你。对于现今许多应用，包括几乎所有的网站都是依赖用户名和密码的，这就是它们所需要的。
But why bother? How is a token issued by a CardSpace “Geneva” self-issued identity provider better than a simple username and password? Unless there are some advantages over what we do today, there’s no reason to switch. These tokens can have significant benefits, however, including the following:
但是为什么？ CardSpace “Geneva” 自颁发标识提供程序（The Self-Issued Identity Provider） 颁发的令牌（Token）比 简单的用户名和密码的好处是什么？ 除非比如今的用户名和密码有些优势，否者我们没有理由来改变。 但是，这些令牌（Token）确实有很大好处，包括如下：
-
Unlike passwords, the SAML tokens created by a self-issued identity provider contain cryptographic complexities that make them unusable by anybody except their true owner. Since these tokens can’t be stolen and reused, the problem of phishing can be significantly reduced.
和密码不同， 自颁发标识提供程序（The Self-Issued Identity Provider） 创建的 SAML 令牌（Token） 包含复杂的加密，能使除了真正的主人以外都不能使用它。由于这些令牌（Token）不能被盗取和重用，所以钓鱼问题将得到很大改善。
-
Rather than making users type in basic personal information, this data can be supplied automatically in the token. Forcing users to go through this kind of registration process is one of the major reasons people give up on accessing a site, and so doing this for them can make the site more usable.
与其让用户输入基本的个人信息，不如让令牌（Token）自动的提供这些数据。强制的让用户进行某种注册过程是让用户放弃继续访问网站的主要原因之一，所以这样做可以让网站更加便于使用。
-
Unlike passwords, which an application must store securely, a token from a self-issued identity provider can be verified using just a public key. Since public keys needn’t be kept secret, applications that accept self-issued tokens don’t need to worry about them being stolen.
自颁发标识提供程序（The Self-Issued Identity Provider） 的令牌（Token） 可以仅仅通过公钥来验证。由于公钥不需要保密，应用程序可以接受 自颁发的令牌（Self-Issued Token） 而不用担心它们被盗取。
In the lexicon of claims-based identity, an information card issued by a self-issued provider is known as a personal card, while one issued by an external identity provider is called a managed card. And just as an application can indicate which external identity providers it will accept tokens from, it can also indicate whether it accepts tokens from self-issued providers. (One more point worth making here: The self-issued provider isn’t included in the first beta release of CardSpace “Geneva”.)
在基于声明的标识（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发行版中。）
In the lexicon of claims-based identity, an information card issued by a self-issued provider is known as a personal card, while one issued by an external identity provider is called a managed card. And just as an application can indicate which external identity providers it will accept tokens from, it can also indicate whether it accepts tokens from self-issued providers. (One more point worth making here: The self-issued provider isn’t included in the first beta release of CardSpace “Geneva”.)
在结束这个 CardSpace 讨论之前， 列出那些在CardSpace “Geneva” 中比较重要的更改。 其一是现在 CardSpace “Geneva” 可以从 .NET Framework 中分离出来，使其更小，速度更快。新版本还对用户反复访问的应用程序做了优化。例如，当你再次访问一个网站的时候，可以直接在页面中显示你最后一次用于登录站点时选择的卡片——CardSpace “Geneva” 屏幕不会出现。在某些情况，用户可以在 CardSpace “Geneva” 选择屏幕中通过勾选一个选项框来反复使用指定的标识（Identity）。此外，微软也在调查让企业的管理员推送策略到桌面，那个策略指定了访问某个网站时应该用什么标识（Identity）。如果这个成功，这些标识（identity）就可以直接使用，用户不再看到 CardSpace “Geneva” 选择器屏幕了。
“Geneva”Framework
An STS provides tokens containing identity information, while an identity selector helps users choose which tokens they’d like to use. Yet both are pointless unless applications are modified to accept and use these tokens. The goal of the “Geneva” Framework is to make it easier to do this, helping developers create claims-aware applications.
STS提供的令牌（Token）包含 标识（Identity）信息， 身份选择器（Identity Selector）可以帮助选择他们选择想要使用的令牌（Token）。除非修改应用程序可以接受和使用这些令牌（Token），否则它们是没有用的。“Geneva” Framework 的目标是使做这个变得更简单，帮助开发者创建声明意识（Claims-aware）的应用程序。
As described earlier, for example, the “Geneva” Framework provides built-support for verifying a token’s signature and extracting its claims. Each claim is extracted into an instance of the “Geneva” Framework-defined Claim class, providing a consistent way for developers to work with a token’s information. This class’s properties include things such as:
例如，先前描述的，“Geneva” Framework 提供对于验证令牌（Token）的签名和提取声明（Claim） 的构建支持（Built-support）。每个提取出来的声明（Claim） 被封装到 “Geneva” Framework 定义的 Claim 类的实例中，为开发者提供了一致的方式来使用令牌（Token）的信息。这个类包含了以下属性：
-
ClaimType, indicating what kind of claim this is. Does the claim contain a user’s name, for example, or a role, or something else? Claim types are identified by strings, which are typically URIs.
ClaimType，指出这个声明（Claim）的类型。例如，声明（Claim）中是否包含用户的名字，或者角色，或者其他什么东西？ 声明（Claim）类型通过典型的URI字符串来识别出来。
-
Value, containing the actual content of the claim, such as the user’s name.
Value，声明（Claim）中包含的实际内容，如用户的名字。
-
Issuer, which specifies the identity provider this claim came from. In other words, this is the entity asserting that this claim is true.
Issuer，指出这个声明（Claim）来至哪个 标识提供程序（Identity Provider）。换句话说，这个实体 断言了这个声明（Claim） 是真实的。
Along with helping developers create claims-aware applications, the “Geneva” Framework also provides support for creating a custom STS. Even though a primary goal of “Geneva” Server is to reduce the need to hand roll your own STS, there are situations where building an STS can make sense. For example, an ISV might use the “Geneva” Framework to create a custom STS for its own purposes.
除了帮助开发者创建 声明意识（Claims-aware）的应用程序外，“Geneva” 框架也提供了对创建自定义的STS支持。虽然 “Geneva” 服务器的主要目标就是减少你制作自己的STS，但是有些情况下建立自己的STS是可以理解的。例如，独立软件开发商（ISV）可以使用“Geneva”Framework 去创建自定义的STS 来达到自己的目的。
There’s a lot more in the “Geneva” Framework, and creators of claims-aware Windows applications will need to become familiar with this library. For a more detailed look at this technology and how to use it, see Keith Brown’s white paper, available at https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=642&DownloadID=12901.
“Geneva” Framework 中还有更多东西，声明意识（Claims-aware）的 Windows应用程序将会喜欢这个类库（“Geneva” Framework）。关于这个技术的更多详细信息和使用方法可以查看 Keith Brow 的白皮书 ，在 https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=642&DownloadID=12901。
CONCLUSIONS
总结
Changing how people and applications work with identity is not a small thing. Given this, widespread adoption of claims-based identity is likely to take some time. Still, the foundation is now in place to make this much-improved approach real.
改变人是和应用程序使用标识（Identity）的方式不是一件小事。鉴于于此，普遍的使用 基于声明的标识（Claims-Based Identity） 还需要一些时间。不过，基金会正在致力于这方面的更多实质性的改善。
With the advent of “Geneva” Server, CardSpace “Geneva”, and the “Geneva” Framework, all of the pieces required to use claims-based identity on Windows are here. While this style of working with identity is far from a Microsoft-only initiative, making these components widely available for Windows is bound to make it more popular. For anyone who cares about improving the way we use identity in the digital world, this is certainly a step forward.
随着 “Geneva” 服务器的出现，CardSpace “Geneva” 和“Geneva” Framework的出现， 所有的这些都是用在 Windows 上的 基于声明的标识（Claims-Based Identity） 。虽然这种与表示（Identity）的工作方式是微软主导的，并使这些组件在更多 Windows 上受欢迎。对于任何关心改善在数字世界中使用标识（Identity）方式的人，这是坚实的迈出一步。
ABOUT THE AUTHOR
关于作者
David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps people around the world understand, use, and make better decisions about new technology.
David Chappell 是加利福尼亚州旧金山 Chappell & Associates (www.davidchappell.com) 的负责人。他通过讲演、撰稿和咨询，帮助全球的技术专业人员了解和使用企业软件，并制定更佳的决策。
![clip_image001[12]](http://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/GENEVABeta13_106/clip_image001%5B12%5D.png "clip_image001[12]")
![clip_image001[14]](http://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/GENEVABeta13_106/clip_image001%5B14%5D.png "clip_image001[14]")
