《介绍 GENEVA Beta 1 白皮书》（2）
有任何问题，可以查看 翻译预告 《介绍 GENEVA Beta 1 白皮书》或者直接在这里回复。
应用 基于声明的标识（Claims-Based Identity） 和 “Geneva”
Getting your mind around claims-based identity requires understanding the basics of this technology. Still, the best way to get a feel for this approach is to walk through examples of how it can be applied. Accordingly, this section looks at several different ways this technology can be used.
想要实现 基于声明的标识（Claims-Based Identity） 有关的想法就需要了解这个技术的基础。因此，最好的学习方式还是 通过 如何应用它 的示例来掌握。因此，本节将看几个关于这个技术的不同使用方式。
Without claims-based identity, application developers are faced with a diverse set of scenarios, each with its own identity solution. One big contribution of claims-based identity is to collapse all of these down to just one problem: How does an application get information about a user from a trusted source? As this section shows, claims-based identity provides a consistent answer across a range of scenarios.
如果没有 基于声明的标识（Claims-Based Identity），应用程序开发者将面临各种情况，每个情况都有自己的 标识解决方案（Identity Solution）。 基于声明的标识（Claims-Based Identity）最大的 好处是使这些问题化解成一个问题： 如何使应用程序从信任的源那里获取用户信息？ 正如本节说明的，基于声明的标识提供程序（Claims-Based Identity Provides） 为这些情形提供了一种统一的解决方式。
Without claims-based identity, application developers are faced with a diverse set of scenarios, each with its own identity solution. One big contribution of claims-based identity is to collapse all of these down to just one problem: How does an application get information about a user from a trusted source? As this section shows, claims-based identity provides a consistent answer across a range of scenarios.
需要强调的是，虽然这些示例展示的是微软的技术，但是不使用他们也是没有问题的。其他供应商提供的产品，如 IBM的Tivoli Federated Identity Manager，也是提供STS 。类似的，其他的 身份选择器（Identity Selector）也是可用的，例如开源的 Higgins ，也可以用其他的类库来创建具有 声明意识（Claims-aware） 的应用程序。 关键的一点是，微软也是一个参与者，向着 基于声明的标识（Claims-Based Identity） 广泛的使用和多个供应商 而努力着。
在企业内部使用声明（Claim）
Every enterprise acts as an identity provider, and virtually every enterprise application must deal with identity. The “Geneva” Server, CardSpace “Geneva”, and the “Geneva” Framework can provide the foundation for using claims-based identity with applications running inside an organization. Figure 7 shows how this looks.
做为每个企业的 标识提供程序（Identity Provider），几乎为企业中的每个应用程序处理身份（Identity）。 “Geneva” 服务器，CardSpace “Geneva”，还有 “Geneva” Framework 都可以提供让运行在企业内部的应用程序使用 基于声明的标识（Claims-Based Identity） 的能力。图7显示了它的样子。
Figure 7: An enterprise can use Active Directory Domain Services, the “Geneva” Server, CardSpace “Geneva”, and the “Geneva” Framework to support claims-based identity for its internal applications.
图7： 使用的 ADDS 的企业， “Geneva” 服务器，CardSpace “Geneva”，还有 “Geneva” Framework 为内部应用程序 提供 基于声明的标识（Claims-Based Identity）的支持。
In this example, a user logs in using AD DS, getting an initial Kerberos ticket (step 1). The user can then access a claims-aware application built using the “Geneva” Framework, learning what kinds of tokens it accepts and what claims those tokens must contain (step 2). If CardSpace “Geneva” is used (it’s not required, remember), the user might then see the screen shown earlier in Figure 6 and select an identity by choosing a card (step 3). CardSpace “Geneva” will then request a token for this identity, supplying a Kerberos ticket to authenticate the user (step 4). The “Geneva” Server STS verifies the ticket, then looks in AD DS for the information it needs to create the requested token (step 5). Exactly what claims appear in this token depend on both the user requesting it and the application that user is accessing—each application indicates exactly what claims it needs. Once the token has been created, the “Geneva” Server STS sends it back to the user’s system (step 6), which sends it on to the application (step 7). The application uses the “Geneva” Framework to verify the token’s signature and make its claims available for use (step 8).
在这个例子中，用户使用ADDS登录，并获取最初的 Kerberos 票据（步骤1）。 然后，用户就可以访问使用 “Geneva” Framework 创建的具有 声明意识（Claims-aware） 的应用程序，并获取应用程序接受令牌（Token）的种类 和令牌（Token）中必须包含的声明（Claims）（步骤2）。如果使用了CardSpace “Geneva”（不是必须的，还记得吗？），用户将会看到先前图6 的画面，然后通过选择一个卡片来选择身份（Identity）（步骤3）。CardSpace “Geneva” 将会为这个身份（Identity）请求令牌（Token），并提供Kerberos 票据 来验证用户（步骤4）。 “Geneva” 服务器 STS 验证 票据（Ticket），然后 查找ADDS 获取用来创建请求令牌（Token）的信息（步骤5）。 令牌（Token）中所包含的声明（Claims）是根据 用户请求的信息和用户要访问的应用程序而决定的，每个应用程序都会明确的指出它所需要的声明（Claims）。一旦令牌（Token）成功创建，“Geneva”服务器 STS 会将它发送回到用户的系统（步骤6），然后 会发送它到应用程序（步骤7）。 应用程序使用 “Geneva” Framework 来验证 令牌（Token）的签名并使声明（Claims）可供使用（步骤8）。
One big plus of a claims-based approach is worth re-emphasizing here: Rather than having to go look for the information it needs about a user, the application can instead get everything handed to it in the token. If the application needs, say, the user’s job title, it can specify this in its list of required claims. When the STS creates a token for the application, it finds the user’s job title in AD DS and inserts it as a claim that the application can use. Without this, the application developer must write his own code to dig this information out of AD DS. Claims-based identity makes the developer’s life significantly easier.
基于声明的（Claims-Based ）方法的一个很大的好处值得再次强调： 应用程序不需要再去查找自己需要的用户信息，相对的应用程序可以在令牌（Token）中得到传递给它的任何信息。 如果应用程序需要，比如，用户的职称（Job Title），它可以指定这个到它的需要的声明（Claims）列表中。当STS 为应用程序创建令牌（Token）的时候，它会 在ADDS 中寻找用户的职称（Job Title），并将它作为声明（Claim）插入到令牌（Token）中，然后应用程序就可以使用了。如果没有这个，应用程序的开发人员必须自己编写代码来在ADDS中搜索信息。基于声明的标识（Claims-Based Identity） 可以使开发人员的工作变得简单。
Along with easing the lives of developers, an STS also performs another function: It acts as a claims transformer. When the client requests a token from the “Geneva” Server in Figure 7, for instance, it provides a Kerberos ticket. This ticket can be thought of as a token containing a simple set of claims (the user’s name and group memberships). The “Geneva” Server STS uses this token to authenticate the user making the request, then emits another token. This new token is in a different format—it’s a SAML token rather than a Kerberos ticket—and it probably contains a different set of claims, since it can include whatever the target application has specified. In a very real sense, the STS has transformed one set of claims into another.
与简化开发人员的工作同时，STS也执行另一个功能：做为 声明转换器（Claims Transformer）。 例如，在图7中， 当客户端 向 “Geneva”服务器请求令牌（Token）时，提供了一个 Kerberos 票据。这个票据可能会影响 令牌（Token）中包含的简单一组声明（如用户的名字和成员组）。“Geneva”服务器 STS 使用这个令牌（Token）来验证用户发出的请求，然后发送另一个令牌（Token）。 这个新的令牌（Token）使用不同的格式——它是SAML令牌（Token）而不是Kerberos票据 ——并且 它可能包含一组不同的声明（Claims），因为它包含 目标程序指定的 任何东西。 你能非常真实的体会到了STS 转换了一组声明（Claims）到另一组中。
在互联网上使用声明（Claim）
Now suppose this organization wishes to make the same application accessible to remote employees via the Internet. Rather than modifying the application to accept username/password logins, a traditional solution, the same claims-based approach can be used—the application remains unchanged. Figure 8 illustrates this scenario.
现在假设这个组织希望同一个程序可以让外部雇员通过互联网访问进来。不用像传统的解决方案那样修改应用程序来接受 用户名/密码 的登录，同样的可以使用 基于声明的（Claims-Based ）方法——应用程序不需要修改。图8 说明了这种情况。
Figure 8: An enterprise can use the “Geneva” Server STS to create tokens for users on the Internet.
图8： 企业可以使用“Geneva” 服务器 STS 来为 在互联网上的用户创建令牌（Token）
Here, the user is on another computer outside the enterprise. As before, this user accesses the application and learns what kinds of tokens it will accept (step 1). Using CardSpace “Geneva” (which is useful but not required), the user selects an identity that meets these requirements (step 2). The user’s system then gets a token for this identity from the enterprise’s STS, implemented using the “Geneva” Server (step 3). It can then submit this token to the application (step 4), which relies on the “Geneva” Framework to verify the token and uses the claims it contains (step 5). Rather than requiring a different way of handling identity for Internet access, as is common today, a claims-based approach allows handling this situation just like the inside-the-enterprise case.
这里，用户在使用另一台在企业外部的机器。与之前一样，该用户访问应用程序并获取它所接受的令牌（Token）类型（步骤1）。使用CardSpace（有用的但不是必须的），用户选择一个满足这些要求的标识（Identity）（步骤2）。然后，用户的系统 为这个标识（Identity）获取令牌（Token），从 使用“Geneva” 服务器 实现的企业的STS 那里（步骤3）。 然后，可以提交这个令牌（Token）到应用程序（步骤4）， 并使用 “Geneva” Framework 来验证 令牌（Token）并使用其中的声明（Claims）（步骤5）。不需要像如今常见的那样，使用不同的方式处理来至互联网访问的标识（Identity），基于声明的（Claims-Based ）方法可以使处理这种情况就像处理企业内部情况一样。
Still, some extra complexity creeps in. When the user requests a token in step 3, for example, how does she authenticate herself to the STS? Kerberos tickets work just fine for users inside the enterprise, as shown earlier in Figure 7, but they don’t work well for Internet users. Instead, the user might provide a username and password in step 3 to authenticate her request, an option that Microsoft plans to support in the “Geneva” Server. Since the users in this scenario are employees, they already have accounts in AD DS, and so they can log in with no trouble.
尽管如此，还是有一些额外的复杂性引入进来。例如，当用户在步骤3中请求令牌（Token）时，她如何让STS来验证她自己的？ 之前图7中显示的 Kerberos 票据 只能用在当用户在企业内部的时候才能使用，而互联网的用户不能使用。 相对的，用户可能在步骤3中提供 用户名和密码 来验证她的请求（一个可选项 微软 计划 在 “Geneva”服务器中支持这个）。 因为在这个情况中的用户是雇员，他们已经拥有了ADDS 帐号，所以他们可以登录，没有任何问题。
Yet what if the users aren’t employees? Suppose the application needs to be exposed via the Internet to customers as well. Can this approach still work? The answer, unsurprisingly, is yes. Although it’s not an especially common option, information about external users can be mingled with employee accounts in AD DS, letting it be accessed by the “Geneva” Server. Alternatively, external user account and attribute information can be stored in Active Directory Lightweight Directory Services (AD LDS). Formerly known as Active Directory Application Mode (ADAM), this technology provides a simpler directory service that’s also an option for the “Geneva” Server.
然而如果用户不是雇员呢？假设应用程序需要通过互联网暴露给客户。这个方法还能工作吗？答案毋庸置疑是肯定的。虽然这不是一个特别常见的选择，外部的用户信息和在ADDS中的雇员帐户一起，都可以被“Geneva” 服务器访问。 选择之一是，外部用户帐户和属性（Attribute）信息被保存到 Active Directory 轻型目录服务（Active Directory Lightweight Directory Services，AD LDS） 中。原名是 Active Directory Application Mode （ADAM），这种技术提供简单的目录服务，这也是 “Geneva” 服务器 的可选项之一。
But wait a minute: If Internet users still need usernames and passwords, how is the claims-based approach making things better? There are a couple of answers. First, recognize that users no longer have a password for each application. Instead, they’ll (at most) have one for each STS they use. This frees applications from the need to store sensitive password information, moving that responsibility instead to the much smaller number of STSs. Also, since requests for tokens are made directly from CardSpace “Geneva”—the user never enters a URL for the STS—phishing for these passwords becomes more difficult. There’s no way for an attacker to slip in a spurious URL for its own STS. While claims-based identity doesn’t necessarily eliminate usernames and passwords, it nonetheless improves the situation.
但等一下： 如果互联网用户仍然需要 用户名和密码，基于声明的（Claims-Based ）方法 如何使这个做得更好？答案有很多。首先，要认识到用户不再为每个应用程序输入密码。相对的，他们将会（大部分）对于使用的STS只会有一个密码。这就使得应用程序从本来需要保存敏感的密码信息的职责中解脱出来，而这个责任被转移到很少的几个STS上。此外，因为请求令牌（Token）是直接由 CardSpace “Geneva” 发出的——用户永远不会进入这个STS的URL—— 要通过钓鱼攻击（Phishing）获取到这些密码也会变得更加困难。攻击者没有办法将指向自己伪造的STS的URL推送给用户。 虽然 基于声明的标识（Claims-Based Identity）不能消除用户名和密码，但是能改善这种情况。
In the case shown in Figure 8, the organization that provides the application is also acting as the identity provider. While this makes sense in many situations, there are other scenarios in which the identity provider is an external organization. For example, Microsoft today offers Windows Live ID as an Internet-accessible STS, and other identity providers also exist. Rather than implementing its own identity provider (or perhaps along with it), an organization can create an application that accepts tokens from external providers like these. Figure 9 shows how this looks.
在图8中显示的，该组织不仅提供了应用程序，也同时担当了标识提供程序（Identity Provider）。 虽然这在很多情况下是合理的，还有一些情况，使用的 标识提供程序（Identity Provider）是外部组织的。例如，如今微软提供的Windows Live ID 就是一个互联网可访问的（Internet-accessible）STS， 还有其他的 标识提供程序（Identity Provider）的存在。虽然可以实现自己的 标识提供程序（Identity Provider）（或者同时使用），但是公司可以创建的应用程序接受来至外部 标识提供程序（Identity Provider）颁发的令牌（Token）。 图9 显示了它的的样子。
Figure 9: An application can accept tokens issued by identity providers run by external organizations.
图9： 应用程序可以接受运行在组织外部的标识提供程序（Identity Provider）所颁发的令牌（Token）
As in the example shown in Figure 8, the process begins with the user accessing the application (step 1), then choosing an identity (step 2). This time, however, the token for this identity is provided by an STS run by an outside identity provider (step 3). Once it has the token, the user’s system submits it to the application as usual (step 4), which uses the claims it contains (step 5).
和图8中的示例一样，过程起始于 用户访问应用程序（步骤1），然后选择标识（Identity）（步骤2）。然而，这次，为这个标识（Identity）请求的令牌（Token）是来至运行在外部的标识提供程序（Identity Provider）的STS 提供的（步骤3）。 一旦有了令牌（Token），用户的系统会和往常一样将令牌（Token）提交到应用程序（步骤4），它会使用其中的声明（Claims）（步骤5）。
Don’t be confused: Even though one of the external identity providers in this example is run by Microsoft, neither CardSpace “Geneva” nor claims-based identity in general are bound to a particular provider. Anybody who implements an STS can act as an identity provider, assuming they can convince applications to trust the claims in tokens they issue.
不要被迷惑：虽然例子中外部的标识提供程序（Identity Provider）之一 是由微软提供的，这绝不是 CardSpace “Geneva” 也不是 基于声明的标识（Claims-Based Identity） 常见的对 提供程序 （Provider）的限制。 任何人都可以实现 STS 来作 标识提供程序（Identity Provider），假设 能使 应用程序信任它们发布的令牌（Token）中的声明（Claims）。
Whether an Internet-accessible application trusts an outside identity provider or only one run by its own organization, a claims-based approach is attractive. It allows handling identity in a consistent way for users inside and outside the firewall. It also gets applications out of the business of maintaining username/password databases for Internet users, making phishing less effective. Along with making developers’ lives easier, claims-based identity can also make things simpler for users. For example, since a token can carry whatever claims an application specifies, users can more easily submit the common information requested by Web sites—they need no longer type it in at each site. While the behavior of thousands of application developers and millions of users won’t change overnight, the long-term prognosis is positive.
不管是互联网可访问的（Internet-accessible）应用程序信任外部的标识提供程序（Identity Provider）或者 仅仅是自己组织运行的标识提供程序（Identity Provider）， 基于声明的（Claims-Based ）方法都是很有魅力的。它可以为防火墙内部和外部的用户提供一致的标识（Identity）处理方式。它也可以使应用程序从维护互联网用户使用的用户名/密码的数据库的工作中解脱出来，这使得钓鱼攻击变得无效。同时也使开发者的工作变得简单， 基于声明的标识（Claims-Based Identity） 也可以简化用户的操作。 例如，因为令牌（Token）中包含任何应用程序指定的声明（Claims），用户可以更简单的 通过网站提交常见信息 —— 用户不需要在为每个网站输入了。虽然，数以千计的应用程序开发者和数以百万的用户 的行为 不会一夜改变，但未来是客观的。
Another common identity challenge is letting users in one organization access an application running in some other organization. For example, suppose your company wishes to make an internal SharePoint site accessible to employees at a partner firm. One way to do this is to give each of these external users their own account in your company. While this approach works, it’s unappealing. Those users won’t like having a separate login, and your firm’s administrators won’t like having to administer accounts for people outside your company. Doing this also creates security risks—how can your administrators know when an external user has left his company and so should no longer have an account?
另一个常见的标识（Identity）挑战是让一个公司中的用户访问运行在另一个公司中的应用程序。例如，假设你的公司希望让在合作伙伴的雇员访问公司内部的SharePoint站点。 有一种办法来是为每个外部的用户分配你的公司的帐号。虽然这个方法可以工作，但却不怎么诱人。这些用户不喜欢使用额外的登录，并且你的公司的管理员也不喜欢去管理公司外部人员的帐号。还有就是这个操作也引来了安全风险——如何知道外部用户什么时候离开了公司，好让你的管理员来关闭这个帐号以不让他使用？
A better solution is to let the external users access your application using their own identities. This approach requires no separate logins and no new accounts. What it does require, however, is creating a federation relationship between your firm and its partner. Doing this will likely require some kind of legal agreement between the two organizations, a topic that’s beyond the scope of this discussion. It also, of course, requires putting in place the right technology.
一个更好的解决方案是让外部用户使用它们自己的标识（Identities）访问你的程序。这个方法不需要单独登录和新的帐号。但是却需要在你的公司和合作伙伴之间建立一个联合关系（Federation relationship）。这样做像是在两个公司间指定某种法律协议，不过这个话题超出了本文讨论范围。当然，也需要把这个技术放到合理的位置。
AD FS, Microsoft’s predecessor to the “Geneva” Server, allowed identity federation for passive clients (that is, for browsers), but not for active clients. The “Geneva” Server still supports the AD FS-style passive option, which relies on a standard called WS-Federation. (If you’re interested in how it works, see Digital Identity for .NET Applications: A Technology Overview, available at http://msdn.microsoft.com/en-us/library/bb882216.aspx .) With CardSpace “Geneva” and STSs, however, claims-based identity can also be used for federated access by active clients. This lets the same identity technology be used in yet another important scenario, and it also offers users more control than did AD FS over which identity they use.
AD FS ，微软的 “Geneva”服务器的前身，允许被动（Passive）客户端（如，浏览器）的联合标识验证（Federation Identity），但是不支持主动（Active）客户端。“Geneva”服务器仍然支持 AD FS 样式的被动选项，通过依赖 WS-Federation 标准。（如果你感兴趣它是如何工作的，可以参考 Digital Identity for .NET Applications: A Technology Overview ， 网址：http://msdn.microsoft.com/en-us/library/bb882216.aspx。） 然而，与 CardSpace “Geneva” 和 STS 一起，基于声明的标识（Claims-Based Identity） 也可以用于主动客户端的联合访问（Federated Access）。这使得同样的标识（Identity）技术被使用在其他重要环境中，同时也比使用ADFS，提供了更多的用户控制。
One approach to providing federated identity in a claims-based world is to configure an application running in one organization to trust an STS in another. Figure 10 shows how this looks.
在基于声明的（Claims-Based）世界中，提供联合标识验证（Federation Identity）方法是配置运行在组织的应用程序去信任另一个组织中的STS。 图10 显示它的样子。
Figure 10: If the application trusts the STS in the client's enterprise, it can accept and use a token issued by that STS.
图10：如果应用程序信任客户端企业的STS，那么它就能接受和使用那个STS颁发的令牌（Token）。
In this scenario, a user in enterprise X accesses an application in enterprise Y and learns its token requirements (step 1). Here, that application is configured to trust both its own STS, the one in enterprise Y, and the STS in enterprise X. All that’s required is for the user in enterprise X to choose an identity that matches this application’s requirements (step 2), then get a token for that identity from its own STS (step 3). The browser or client submits this token to the application (step 4), which uses the “Geneva” Framework to verify the token and extract its claims. The application can then use these claims any way it likes (step 5).
在这个情况中， 在企业X中的用户访问在企业Y中的应用程序并获取需求信息（步骤1）。在这里，应用程序配置成信任着2个STS，在企业Y中的STS和在企业X中的 STS。 然后需要在企业X中的用户来选择一个满足应用程序需求的标识（Identity）（步骤2），然后从自己的STS那为这个标识（Identity）获取令牌（Token）（步骤3）。浏览器或客户端提交这个令牌（Token）到应用程序（步骤4）， 然后使用 “Geneva” Framework 来验证令牌（Token）并提取其中的声明（Claims）。应用程序可以使用任何它喜欢的方式使用这些声明（Claims）（步骤5）。
This solution is simple, but it’s not without problems. Suppose this application has users in several different enterprises, for instance. With the approach shown in Figure 10, the application would need to be configured to trust the STS in each one, an unappealing prospect. A better solution is to let the mechanics of federated identity be handled by the STSs themselves. Doing this means that an application only needs to trust its own STS, making life significantly simpler for the people who build and administer it. Figure 11 shows this more likely situation.
这个解决方案很简单，但不是没有问题。假设例子中的程序被几个不同企业中的用户使用。使用图10 中的方法，应用程序需要配置信任每一个STS，这将会前景灰暗。更好解决方法是使用联合标识验证（Federation Identity） 的机制通过自己的STS处理。这样做意味着应用程序仅需要信任自己的STS，使构建者和管理的工作变得简单。图11显示了这个更适合的情况的样子。
Figure 11: If the application trusts only the STS in its own enterprise, the client must get a token from that STS to access the application.
图11：如果应用程序只信任自己的企业的STS，那么客户端必须向那个STS请求令牌（Token）来访问程序。
This scenario starts in the same way: The user in enterprise X accesses an application in enterprise Y and learns its token requirements (step 1). This time, however, that application is configured to trust only its own STS, the one in enterprise Y. Once it determines this, CardSpace “Geneva” on the user’s system contacts the STS in enterprise Y to learn its token requirements (step 2). Along with its identity selector role, CardSpace “Geneva” also has built-in intelligence to traverse this kind of federation relationship. CardSpace “Geneva” then prompts the user to select an identity (i.e., a card) that matches those requirements (step 3) and requests a token for this identity from the enterprise X STS (step 4). This token contains claims about the user, but it’s not a token that the application will accept—it was issued by an STS that the application doesn’t trust. Instead, CardSpace “Geneva” submits this token to the STS in enterprise Y (step 5). This STS is configured to trust the STS in enterprise X, a relationship that must be established explicitly by administrators in the two organizations. (How this trust relationship gets created is described in a bit more detail later.) Because of this trust, the STS in enterprise Y can verify the token it receives from enterprise X, then issue a token that allows this user to access the application (step 6). The user presents this token to the application (step 7), and the application uses the “Geneva” Framework to verify the token and extract its claims. The application can now use these claims as usual (step 8).
这个情况中和之前一样的地方开始： 企业X中的用户访问企业Y中的应用程序并获取它的令牌（Token）需求信息（步骤1）。然而，这次应用程序配置成仅信任自己的STS，即 在企业Y中的STS。一旦确认了这个，在用户系统上CardSpace “Geneva” 将会联系在企业Y中的STS来获取它的令牌（Token）需求（步骤2）。同时作为 身份选择器（Identity Selector）角色，CardSpace “Geneva”内置的智能能够穿透这种联合关系（Federation relationship）。然后，CardSpace “Geneva” 提示用户来选择满足这些需求的标识（Identity）（如，通过卡片）（步骤3）并且为这个标识（Identity）从企业X的STS那里请求令牌（Token）（步骤4）。这个令牌（Token）包含了关于这个用户的声明（Claims），但是这个令牌（Token）将不会被应用程序接受——颁布它的STS不是应用程序信任的。相对的，CardSpace “Geneva”提交这个令牌（Token）到在企业Y中的STS（步骤5）。这个STS被配置成信任在企业X中的STS，这种关系必须是通过两个企业的管理员详细的制订出来的。（有关如何创建者这种信任关系的描述的详细信息在后面。） 因为这中信任，在企业Y中的STS可以验证令牌（Token）是来至企业X的，然后发布令牌（Token）来允许用户访问应用程序（步骤6）。用户向应用程序出示这个令牌（Token）（步骤7），并且应用程序使用 “Geneva” Framework 来验证令牌（Token）并提取其中的声明（Claims）。现在应用程序可以使用这些声明（Claims）了（步骤8）。
It’s worth pointing out that even though the “Geneva” Server was shown as one of the STSs in both of these federation scenarios, it’s not required. CardSpace “Geneva” can communicate with any STS from any vendor. Note too that the STS in enterprise Y is acting as a claims transformer, accepting a token issued by STS X, then creating its own token. The contents of the token STS Y creates might well be different from those in the token it receives from STS X—it’s free to add, remove, or modify the claims.
值得说明的是即使在这两个情景中，“Geneva”服务器出现在STS之中，但它不是必须的。CardSpace “Geneva” 可以和任何供应商的任何STS通讯。还注意到在企业Y中的STS作为声明转换器（Claims Transformer），接受 STS X 颁发的令牌（Token），然后创建自己的令牌（Token）。STS Y创建的令牌（Token）内容可能和从STS X接受过来的令牌（Token）不同——可以随意的添加，删除，或者修改声明（Claims）。
And finally, think again about how convenient it is for the application to get the information it needs about a user directly in the token. When both user and application are in the same organization, the application might be able to access, say, AD DS directly to get information such as the user’s job title. When they’re in different organizations, as in the federated case shown here, the application almost certainly won’t be allowed to do this. Getting everything it needs handed to it in the user’s token is very nice indeed.
最后，重新思考一下，直接使用令牌（Token）如何方便了应用程序获取需要的有关用户的信息。当用户和应用程序都在用一个组织的时候，应用程序可能访问，如，从AD DS 直接获取信息像是用户的职称。而当他们在不同的组织中的时候，如这里展示的联合示例，应用程序几乎可以肯定的将不会被允许这样做。 把需要的任何东西放到用户的令牌（Token）中是个不错的选择。
通过代理使用声明（Claim）
Here’s yet another identity challenge: Suppose one application needs to access another application on behalf of some user. Solving this problem requires identity delegation, where the application that receives a user’s identity information is allowed to act as that user when accessing another application. While delegation has long been important, it becomes even more significant in a service-oriented world, where one service depends on another. Once again, claims-based identity can be used. Figure 12 shows how.
这里又有另一个标识（Identity）挑战：假设一个应用程序需要代表某些用户访问另一个应用程序。要解决这个问题需要标识代理（Identity Delegation），应用程序接收用户的标识（Identity）信息并允许作为用户来访问另一个应用程序。虽然代理（Delegation）方式一直以来很重要，甚至对 面向服务（Service-Oriented）的世界带来重大的影响，一个服务依赖另一个服务。再次重申，基于声明的标识（Claims-Based Identity）可以使用在这里。图12显示如何工作的。
Figure 12: Claims-based identity can be used with delegation, where one application invokes another on a user’s behalf.
图12：基于声明的标识（Claims-Based Identity） 可以与代理一起使用，应用程序代表用户访问另一个应用程序。
This slightly simplified example begins with the user’s browser or other client getting a token for application X (step 1). (Although it’s not shown here, assume this relied on the usual steps shown in earlier figures.) This token is then sent to application X (step 2). To carry out the user’s request, application X needs to invoke a service provided by application Y. X might be a Web application, for example, invoking a Web service in Y using WCF, or X itself might have been invoked via a Web service. In any case, application X needs a token for application Y that contains claims describing the original user. To get this token, application X accesses application Y and learns its token requirements (step 3). Among these is an indication of an identity provider (and thus an STS) from which Y will accept a token. In this example, that STS is the same one that issued the token for application X, although this need not be the case. Here, however, application X can request a token for application Y from the STS they both share, indicating that it wishes to act as the original user (step 4). A “Geneva” Server STS can contain policies describing which applications are allowed to access which other applications using delegation. The STS checks this policy (step 5), which in this case allows application X to invoke application Y on behalf of this user. The STS then issues the requested token allowing X to access Y on this user’s behalf (step 6). Application X passes this token to Y when it invokes the service (step 7). Y then verifies the token using the “Geneva” Framework and uses its claims (step 8).
这个简单的例子开始于用户的浏览器或者客户端获取应用程序X的令牌（Token）（步骤1）。（虽然没有出现在这里，假设这需求信息的通常步骤显示在先前的图例中。）然后这个令牌（Token）发送给应用程序 X（步骤2）。为了完成用户的请求，应用程序 X 需要调用应用程序Y提供的服务。应用程序 X 可能是一个 Web应用程序，例如，调用应用程序 Y 使用WCF建立的Web服务，或者应用程序 X 自身可能通过 Web 服务被调用。无论哪种情况，应用程序 X 需要用于应用程序 Y 的令牌（Token），它包含描述原始用户的声明（Claims）。 要获取这个令牌（Token），应用程序 X 访问应用程序 Y 并获取它的令牌（Token）需求信息（步骤3）。在这些需求信息中，指出应用程序 Y 可以接受的令牌（Token）的标识提供程序（Identity Provider）（像是STS）。在这个例子中，这个STS和为应用程序 X 颁发令牌（Token）的STS是同一个，虽然不一定非给如此。然而，这里应用程序 X 为应用程序 Y 请求令牌（Token）的STS是它们共用的，并指出应用程序 X 希望代表原始用户（步骤4）。 “Geneva” Server STS 可能包含一个策略 用来描述允许哪个应用程序通过使用代理的方式访问另一个应用程序。STS检查这个策略（步骤5），在这里个例子里允许应用程序 X 代表 用户访问 访问应用程序 Y。然后 STS 发布允许应用程序 X 代表用户访问应用程序 Y 的请求令牌（Token）（步骤6）。 当应用程序 X 调用应用程序 Y 的服务时，应用程序 X 会传递这个令牌（Token）（步骤7）。然后 应用程序 Y 使用 “Geneva” Framework 验证令牌（Token）并使用其中的声明（Claims）（步骤8）。
It’s worth comparing this claims-based style to today’s more common approaches to delegation. One alternative is for the user to pass her username and password directly to application X, which then uses these to access application Y as this user. Yet X now has the user’s login information and so might do other things that the user doesn’t approve of. With the claims-based approach, X has only a token for this user to access Y, nothing more. Another way to provide delegation is to make X a trusted subsystem, an application with complete access to other services. While this can work, granting application X this wide latitude requires placing a great deal of faith in the people who build and run it. This approach also makes it impossible for Y to know which users are accessing it, something that might be required for auditing or other reasons. Claims-based delegation lets X access Y on behalf of individual users, preserving Y’s knowledge of those users, with no need to grant broad trust to X.
值得比较的是这个基于声明的（Claims-Based ）形式和如今的常见的形式相比更是代理（Delegation）。 一个选择是用户直接传递她的用户名和密码到应用程序 X，然后作为这个用户使用用户名和密码来访问应用程序Y。 然而应用程序X现在已经拥有了用户的登录信息，所以应用程序X可能去做其他用户不允许的事情。如果使用基于声明的（Claims-Based ）方法，应用程序X仅拥有这个用户用于访问Y的令牌（Token），没有其他多余信息。另一个方法是提供一个代理（Delegation），一个使应用程序X信任的子系统（Subsystem）， 向应用程序提供完整的访问其他服务的能力。 虽然这个可以工作，但是要授予应用程序 X这种宽广的权利需要对于构建和运行它的人有足够信心（译注：前边说的安全问题）。这个方法也使的应用程序Y 不能知道哪些用户正在访问它，因为审计或者其他原因的需求可能需要记录这些信息（译注：哪些用户访问）基于声明的（Claims-Based ）代理让应用程序 X 代表个别用户访问 应用程序 Y， 并确保 应用程序Y知道这些用户，不需要扩大信任到整个应用程序 X。
Once again, notice that the STS is acting here as a claims transformer. It receives a token for X, then emits a token for Y. These two tokens probably contain different claims, since they’re for different applications, and they might even use different formats. (Applications X and Y might have been built at different times by different people, for example.) All of this variation is hidden from the application developer—and from the user—by the STS. This is yet another example of one of the primary goals of claims-based identity: making applications simpler.
再一次强调，STS 在这里作为一个声明转换器（Claims Transformer）。它接收来至应用程序X的令牌（Token）然后发出给应用程序 Y 的令牌（Token）。这两个令牌（Token）可能包含不同的内容，因为他们是对两个不同的程序颁发的，甚至可能使用了不同的格式。（例如，应用程序 X和 Y可能由不同的人在不同的时间建立的。） 所有这些变化对于应用程序开发者和用户都是通过STS隐藏的。 这也是基于声明的标识（Claims-Based Identity）主要目标之一的另一个例子：使应用程序更简单。