有任何问题，可以查看 翻译预告 《介绍 GENEVA Beta 1 白皮书》或者直接在这里回复。
INTRODUCING “GENEVA”
AN OVERVIEW OF THE “GENEVA” SERVER, CARDSPACE “GENEVA”, AND THE “GENEVA” FRAMEWORK
介绍 “GENEVA”
概述 “GENEVA” 服务器， CARDSPACE “GENEVA”，和 “GENEVA” FRAMEWORK 。
UNDERSTANDING CLAIMS-BASED IDENTITY
了解 基于声明的标识（Claims-Based Identity）
For people who create software today, working with identity isn’t much fun. First, a developer needs to decide which identity technology is right for a particular application. If the application will be accessed in different ways, such as within an organization, across different organizations, and via the public Internet, one identity technology might not be enough—the application might need to support multiple options. Next, the developer needs to figure out how to find and keep track of identity information for each of the application’s users. The application will get some of what it needs directly from those users, but it might also need to look up other information in a directory service or someplace else.
今天，对于开发软件的人们，制作使用身份标识（Identity）的程序已经不是那么有趣了。首先，开发员需要为某个程序选择一个合适的 身份标识技术（Identity Technology）。如果可以通过不同的方式访问程序，如在一个组织里的访问，跨越不同组织访问，还有通过公共互联网的访问，一个 身份标识技术（Identity Technology）可能不够用——程序可能还需要支持多个可选的技术。然后，开发人员需要解决如何 寻找和保持 应用程序 每个用户的身份信息（Identity Information）。 应用程序将会直接从这些用户中获取一些信息，但也可能需要查找其他信息通过目录服务（directory service）或者其他地方。
This is all more complex than it needs to be. Why not create a single interoperable approach to identity that works in pretty much every situation? And rather than making applications hunt for identity information, why not make sure that this single approach lets users supply each application with the identity information it requires?
比上面的还复杂的需求是，为什么不创建一个共用操作方法用来在每个相似的情况下获取身份标识（Identity）？或者制作程序寻找身份信息（Identity Information），为什么不确保这个一个方法可以让用户提供每个程序所需要的 身份信息（Identity Information）？
Claims-based identity achieves both of these goals. It provides a common way for applications to acquire the identity information they need from users inside their organization, in other organizations, and on the Internet. Along with making the lives of developers significantly simpler, a claims-based approach can also lower the cost of building and managing applications.
基于声明的标识（Claims-Based Identity） 实现了这两个目标。它提供一种通用的方式，让应用程序可以获取在组织内部的，在其他组织的，和在互联网上的用户 身份信息（Identity Information） 。 基于声明的（Claims-Based）方法也可以降低构建和管理程序的费用，同时也简化了开发人员的工作。
Making claims-based identity real requires developers to understand how and why to create claims-based applications. It also requires some infrastructure software that applications can rely on. This overview describes the basics of claims-based identity, then looks at how a group of forthcoming Microsoft technologies—the “Geneva” Server, Windows CardSpace “Geneva”, and the “Geneva” Framework—help make this world a reality. All three are still in beta, so be aware that some things might change before their final release. Still, it’s not too soon to begin understanding how this future looks and how we’re going to get there.
要制作 基于声明的标识（Claims-Based Identity） 需要开发人员理解如何和为什么 要创建 基于声明的应用程序（Claims-Based Applications） 。 同时，应用程序也需要依赖一些软件基础需求。本概述将描述基于声明的标识（Claims-Based Identity） 基本原理，然后看看微软即将推出的一组技术——“Geneva ”服务器，Windows CardSpace “Geneva” ，和 “Geneva” Framework——将有助这个成为现实。所有3个组件目前仍是测试阶段，所以，你应该知道在最终发布前可能会有变动。不过，这不是太早开始了解这一前景以及我们如何使用。
Sometimes, working with identity is simple. Think of a Windows application that doesn’t need to know much about its users, for example, and that will be accessed only by users within a single organization. This application can just rely on Kerberos, part of Active Directory Domain Services (AD DS, formerly known as just “Active Directory”), to authenticate its users and convey basic information about them. Or suppose you’re creating an application that will be accessed solely by Internet users. Again, the common approach to handling identity is straightforward: require each user to supply a username and password, then maintain a database of this user information.
有时候，使用标识（Identity）是很简单的。例如，想想Windows程序，它不需要了解太多关于它的用户，程序只能被单个组织内的用户访问。这个程序可以仅仅依赖 Kerberos ，和一部分 Active Directory Domain services （AD DS，就是大家知道的 “活动目录（AD）”），去来认证程序的用户并转发关于用户的基本信息。或者，假设你创建了一个程序，它可以让用户通过互联网访问。同样，常见处理标识的方法很简单：需要每个用户提供一个用户名和密码，然后从数据库中获取这个用户的信息。
Sometimes, working with identity is simple. Think of a Windows application that doesn’t need to know much about its users, for example, and that will be accessed only by users within a single organization. This application can just rely on Kerberos, part of Active Directory Domain Services (AD DS, formerly known as just “Active Directory”), to authenticate its users and convey basic information about them. Or suppose you’re creating an application that will be accessed solely by Internet users. Again, the common approach to handling identity is straightforward: require each user to supply a username and password, then maintain a database of this user information.
然而，在这些简单的情况下也会很快的瘫痪掉。要是你需要了解每一个用户更多的信息，而不仅仅是一个用户名/口令 或 Kerberos ，该怎么办呢？ 你的程序将需要从其它源那里获取信息，比如： ADDS 或者 应用程序自己持有的信息。或者，假设程序必须能让组织内部的雇员访问，还有 客户 可以通过 互联网访问，该怎么让程序同时支持Kerberos和基于用户名/密码 的登录？还有什么情况下，你想让从业务伙伴的用户访问这个组织不需要单独的登录操作？这种身份联合（Identity Federation）不能很好的使用 Kerberos 或 用户名/密码，或者其他的登录方式。
Yet these simple scenarios quickly break down. What if you need more information about each user than is provided by either Kerberos or a simple username and password? Your application will now need to acquire this information from some other source, such as AD DS, or keep track of the information itself. Or suppose the application must be accessed both by employees inside the organization and by customers via the Internet—what now? Should the application support both Kerberos and username/password-based logins? And what about the case where you’d like to let users from a business partner access this organization without requiring a separate login? This kind of identity federation can’t be accomplished very well with either Kerberos or username/password logins—more is required.
合理的解决方法是 有一个获取标识（Identity）的方法，用于所有这些情况。为了使其有效，这个方法必须给是基于跨平台互操作和组织界限并被广泛认可的工业标准。但是，仅仅是标准还是不够的。解决方案也需要多个产品供应商的产品中广泛实施，并且简化开发人员的使用。这种统一，得到广泛支持的方法正是 基于声明的标识（Claims-Based Identity） 所要提供的方法。
Claims-based identity is a straightforward idea, founded on a small number of concepts: claims, tokens, identity providers, and a few more. This section describes the basics of this technology, starting with a look at these fundamental notions.
基于声明的标识（Claims-Based Identity）是个简单的思想，建立在少数的几个概念上，如：声明（Claims），令牌（Tokens），标识提供程序（Identity Provider）等。本节将介绍这种技术的基础，首先看看这些基本概念。
Before launching into this description, however, there’s an important point to make. While this paper focuses on the mechanics, using the technology described here can require more, such as business agreements between different organizations. Addressing the technical challenges is essential, but they’re not always the entire story.
但在开始说明之前，有个一点要说明。这篇文章专注于过程，使用技术描述这里可能需要很多，像是如不同企业间的商业协议等。技术的挑战是必不可少的，但并不是全部。
What is an identity? In the real world, the question is hard to answer—the discussion quickly veers into the metaphysical. In the digital world, however, the answer is simple: A digital identity is a set of information about somebody or something. While all kinds of entities can have digital identities, including computers and applications, we’re most often concerned with identifying people. Accordingly, this overview will always refer to things with identities as “users”.
什么是标识（Identity）？在现实世界中，这个问题很难回答——讨论会很快的变成理论上的。然而，在数字世界里，答案很简单：一个数字标识（Digital Identity）是关于某人或某物的一组信息。任何实体都有数字标识，包括计算机和应用程序，以及我们最关心的识别（Identifying）使用者。所以，本概述中的标识将指为“用户”。
When a digital identity is transferred across a network, it’s just a bunch of bytes. It’s common to refer to a set of bytes containing identity information as a security token or just a token. In a claims-based world, a token contains one or more claims, each of which carries some piece of information about the user it identifies. Figure 1 shows how this looks.
当数字标识（Digital Identity）跨网络传输时，它仅仅是一堆字节。通常情况下，它包含了标识信息（Identity Information），像是安全令牌（Security Token） 或者 只是 令牌（Token）。在 基于声明的（Claims-Based）世界里，一个 令牌（Token）包含一个或多个声明（Claims），每一个都包含了用于识别（identifies） 用户的一点信息。图1显示了它的样子。
图1：一个令牌（Token）包含关于用户的声明（Claims），和用于验证颁发者的数字签名。
Claims can represent pretty much anything about a user. In this example, for instance, the first three claims in the token contain the user’s name, an identifier for a group she belongs to, and her age. Other tokens can contain other claims, depending on what’s required. To verify its source and to guard against unauthorized changes, a token’s issuer digitally signs each token when it’s created. As Figure 1 shows, the resulting digital signature is carried with the token.
声明（Claims）可以描述关于的用户几乎全部信息。例如，前面的实例中，在令牌（Token）中包含了 用户的名字，一个她所属组的标记（identifier）和 她的年龄 的3个声明。其它的令牌（Token）也可能根据需要包含额外的他声明（Claims）。为了验证令牌的来源和避免篡改，令牌的颁发者（Token's Issuer）将在建立令牌（Token）的时候使用数字签名。像图1中显示的，令牌（Token）中携带了一个签名。
But who issues tokens? In a claims-based world, tokens are created by software known as a security token service (STS). Figure 2 illustrates the process.
但是，谁发布令牌（Token）？在基于声明的（Claims-based）世界中，令牌（Token）通过像是 安全令牌服务（Security Token Service，STS）这样的软件创建。图2说明这个过程。
图2：用户从 安全令牌服务（STS）获取包含一组声明（Claims）的令牌（Token）。
In a typical scenario, an application working on behalf of a user, such as a Web browser or another client, asks an STS for a token containing claims for this user (step 1). This request is made using the standard protocol WS-Trust. (In fact, support for WS-Trust is one of the defining characteristics of an STS.) This request is authenticated in some way, such as by providing a Kerberos ticket, a password from the user, or something else. The request typically contains both the name of the user for whom this token should be issued and a URI identifying the application the user wishes to access. The STS then looks up information about the user and the application in a local database (step 2). As the figure shows, this database maintains account information and other attributes about users and applications. Once the STS has found what it needs, it generates the token and returns it to the requester (step 3).
通常情况下，应用程序（像是Web浏览器或者其他客户端）代表用户向STS请求包含这个用户声明（Claims）的令牌（步骤1）。这个请求使用标准协议 WS-Turst。（事实上，支持WS-Trust是STS的功能之一。）这个请求将通过某种方式被验证，如提供了一个Kerberos票据，或 用户的密码，或者其他什么东西。请求通常包含 要发布令牌（Token）所表示用户的名字 和 一个 用户希望访问的应用程序的URI标识（URI Identifying）。 然后，STS在应用程序本地数据库中查找用户信息（步骤2）。如图所示，这个数据库包含账户信息和其它有关用户和应用程序的属性（Attributes）信息。 一旦STS找到它需要的，将会生成令牌（Token）并将它返回到请求者（步骤3）。
如在图2中所示的，一个 STS 拥有 一些 标识提供程序（Identity Provider）（有时也叫做 颁发者（Issuer））。 标识提供程序（Identity Provider）是STS创建令牌（Token）中信任声明（Claims）的后盾。事实上，这也是为什么令牌（Claims）中的内容被叫做 “声明（Claims）”：标识提供程序（Identity Provider）断言他们是真实的。接收这个令牌（Claims）的应用程序可以决定是否信任这个标识提供程序（Identity Provider）以及它所生成的关于用户声明（Claims）。
Identity providers come in many forms. If you use a token issued by an STS on your company’s network, for example, the identity provider is your company. If you use a token issued by the STS provided by Microsoft’s Windows Live ID service on the Internet, this Microsoft service is acting as the identity provider. It’s even possible to act as your own identity provider, a handy option that’s described later.
标识提供程序（Identity Provider） 可以有多种提供形式。例如，如果使用企业内部网络上的STS颁发令牌的话， 标识提供程序（Identity Provider） 是你的公司的。或者，如果使用在互联网上 微软的Windows Live ID 服务提供STS 发布令牌，那么 微软服务将作为标识提供程序（Identity Provider） 。甚至，可以方便的将它作为自己的标识提供程序（Identity Provider） ，这将在稍后将会说明。
Whoever the identity provider is, being able to acquire and use a token full of claims is useful. In the pre-claims world (that is, in the world we mostly live in today), an application usually gets only simple identity information from a user, such as her login name. All of the other information it needs about that user must be acquired from somewhere else. The application might need to access a local directory service, for instance, or maintain its own application-specific database. With claims-based identity, however, an application can specify exactly what claims it needs and which identity providers it trusts, then expect each user to present those claims in a token issued by one of those providers. A claims-aware application is still free to create its own user database, of course, but the need to do this shrinks. Instead, each request can potentially contain everything the application needs to know about this user.
无论使用哪种 标识提供程序（Identity Provider） ，对于用来获取填充令牌（Token）的 声明（Claims） 都是不可或缺的。在声明世界之前（Pre-claims world）（也就是，我们现在生活的世界），应用程序通常从用户那里只获取简单的 身份信息（Identity Information），如 她的登录用户名。 所有关于用户的其他信息必须通过其他地方获取。例如，应用程序可能通过 本地目录服务（Local Directory Service）获取信息，或者通过维护应用程序自身的（Application-specific）数据库。但是，在 基于声明的标识（Claims-Based Identity） 中，应用程序可以指定它需要的 声明（Claims）和它所信任的 标识提供程序（Identity Provider），然后，期待每个用户向其出示的令牌（Token） 中的 声明（Claims） 是 这些信任提供程序之一 颁发的。当然， 声明意识（Claims-aware）的应用程序也需要建立自己的用户数据库，不过，可能需要精简一些。相对的，每个请求中可能包含应用程序需要知道的关于用户的每个信息。
Claims can convey a variety of information. As Figure 1 showed, a claim might contain traditional things such as a user’s name and group memberships, generally useful information such as her address, or other descriptive data such as her age. A claim might also identify the roles a user can act in, providing more information that the application can use to make an access control decision. Yet another possibility is to use a claim to indicate explicitly the user’s right to do something, such as access a file, or to restrict some right, such as setting an employee’s purchasing limit. Because an application can count on getting the identity information it needs in a token, claims-based identity makes life simpler for application developers.
声明（Claims）可能包含各种信息。像图1中显示的，一个声明（Claim）可能包含传统信息，像是用户的名字和所属的组织小组。或者其它有用信息，如她的住址，或者其他描述信息，如她的年龄。声明（Claim）也可以用来确定（Identify）用户角色可以做什么，或者提供更多信息，应用程序可以使用它来做访问控制。 声明（Claim）也可以用来明确的指出用户做事的权利，如访问文件，或是限制某些权利，比如，设置雇员的消费额度。因为应用程序可以从令牌（Token）中获取它所需要的 身份信息（Identity Information），所以，基于声明的标识（Claims-Based Identity）可以使 应用程序开发人员的工作变得简单。
This approach also brings one more benefit: It gets developers out of the business of authenticating users. All the application needs to do is determine that the token a user presents was created by an STS this application trusts. How the user proved its identity to this STS—with a password, a digital signature, or something else—isn’t the application’s problem. This lets the application be deployed unchanged in different contexts, a significant improvement over the usual situation today.
这种方法也来带一个好处：它可以避免开发人员去做认证（Authenticating）用户的任务。应用程序所需要做的是确认 创建 用户所使用令牌（Token）的 STS 是应用程序所信任的。用户如何向STS证明自己的身份（Identity）——通过 密码， 数字签名或者其他什么东西，这将不是应用程序的问题了。这允许应用程序部署在不同的环境下保持不变，大大改善了今天的局面。
使用声明（Claims）
Claims, tokens, identity providers, and STSs are the foundation of claims-based identity. They’re all just means to an end, however. The real goal is to help a user present her digital identity to an application, then let the application use this information to decide what she’s allowed to do. Figure 3 shows a simple picture of how this happens.
声明（Claims）、令牌（Tokens）、标识提供程序（Identity Provider），还有 令牌安全服务（STS） 都是创建 基于声明的标识（Claims-Based Identity）的必要基本功能。然而，这都只是手段。真正的目标是帮助用户向应用程序出示她的数字身份（Digital Identity），然后让应用程序使用这个信息决定她能做什么。 图3 显示 这个是如何发生的简单图例。
![clip_image001[27]](http://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/5eb3a6f931da_A1/clip_image001%5B27%5D.png "clip_image001[27]")
Figure 3: A browser or other client can acquire a token from an STS, then present this token and the claims it contains to an application.
图3：浏览器或者其他客户端从STS获取令牌（Token），然后 出示这个令牌 并且 其中包含 到应用程序的声明（Claims）。
As the figure shows, a Web browser or other client acting on behalf of a user gets a token for a particular application from an STS that’s owned by some identity provider (step 1). Once it has this token, the browser or client sends it to the application (step 2), which attempts to verify its signature. If this verification works, the application knows which STS, and thus which identity provider, issued the token. If the application trusts this identity provider, it assumes the claims in the token are correct and uses them to decide what the user is allowed to do (step 3).
如图所示，浏览器或客户端 代表用户 向拥有某个标识提供程序（Identity Provider）的STS 请求用于特定程序的令牌（Token）（步骤1）。一旦获得这个令牌（Token)，浏览器或客户端将发送它到应用程序（步骤2），应用程序将尝试验证它的签名。在核查工作中，应用程序知道了哪个 识提供程序（Identity Provider）的 哪个 STS发布的令牌（Token）。如果应用程序信任这个标识提供程序（Identity Provider），它将假设令牌中的声明（Claims）是正确的并使用他们决定用户可以做什么（步骤3）。
If the token contains the user’s name, for example, the application can assume that the user really is who she claims to be. Since the user was required to authenticate herself to get this token, as described earlier, the application doesn’t need to authenticate her again. In fact, because it relies on the claims in the token, an application is sometimes referred to as a relying party.
例如，如果令牌（Token）中包含用户的名字， 应用程序将会假设用户她是声明中的那个人。由于用户需要通过认证（Authenticate）才能获取到她自己的令牌（Token），如前所述，所以应用程序不需要再次认证她。事实上，正因为依赖令牌（Token）中的声明（Claims），所以 应用程序有时也被称作 依赖方（Relying Party）。
If the token contains the user’s name, for example, the application can assume that the user really is who she claims to be. Since the user was required to authenticate herself to get this token, as described earlier, the application doesn’t need to authenticate her again. In fact, because it relies on the claims in the token, an application is sometimes referred to as a relying party.
虽然没有显示在图上，但是在发生这些事情之前还有一个必须要做的事：管理员必须配置STS来为应用程序和用户发布正确（Right）的声明（Claims）。如果不这么做，没有办法来使STS来创建包含应用程序所需要声明（Claims）的令牌（Token）。虽然这样做似乎是重担，但事实是这一信息也必须配置到 非基于声明的（Non-Claims-based）世界。最大区别在于，现在通过STS所有需要的声明（Claims）都集中在一起，而不是分散在各个系统中。
The implicit assumption in Figure 3 is that the user has just one digital identity that she uses for all applications. The truth, though, is that she probably wishes to send different identity information to different applications. Think about how this works in the real world: You show your passport to a border guard, but give your driver’s license to a traffic cop. Neither will accept the identity demanded by the other, because different situations require presenting different information from different sources. Passports are issued by national governments, while driver’s licenses might be issued by some more local entity, such as a state government. The analog in the digital world is relying on different identity providers, each offering an STS that issues tokens containing appropriate claims. The claims in these tokens vary, just as the information in your passport is different from what’s in your driver’s license.
在图3中隐含这样的一个假设，用户她对所有应用程序都只用一个数字身份（Digital Identity）。虽然，事实是她可能希望向不通的程序发送不同的身份信息（Identity Information）。想想这个在现实世界中怎么做的：你向边防出示护照（Passport），但是给你颁发驾照（Driver's License）的是交通警察。绝不接受其他的身份（Identity），因为不同的情况需要出示来至不同源的不同的信息。护照是由联邦政府（national governments）部门颁发的，而驾照则是由本地的部门颁发的，如州府。在数字世界中模拟这种情况就是 依赖 不同的 标识提供程序（Identity Provider），每个可用的STS将发布包含 合适声明（Claims）的令牌（Token）。这些令牌（Token）中的声明（Claims）都各不相同，就像你护照中的信息和你的驾照的不同。
If we’re all going to have multiple digital identities—and we are—it would be useful to have a consistent way to select the identity we want to use to access a particular application at a particular time. In other words, we’d like to have an identity selector. Figure 4 shows where this component fits.
如果我们有多个数字身份（Digital Identities），并且我们使用一种统一方式来选择 每次我们要访问的特定程序时，所使用的身份。换句话说，我们需要一个 身份选择器（Identity Selector）。图4 显示了这个组件合适的位置。
![clip_image002[11]](http://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/5eb3a6f931da_A1/clip_image002%5B11%5D.png "clip_image002[11]")
Figure 4: An identity selector provides a consistent way for users to choose which identity they wish to present to an application.
图4：身份选择器（Identity Selector）为用户 提供了一种统一方式，来选择希望向到程序出示的身份。
In this more complete illustration, the process begins when the user accesses the application. Whether it’s contacted from a browser or some other client, the application can indicate what kind of token it requires, what kind of claims that token should contain, and what identity providers it trusts (step 1). As always in a claims-based world, the application can do this in a vendor-neutral way, using either WS-SecurityPolicy (for requests made via SOAP) or HTML (for requests made via HTTP) to describe these requirements. Once the user’s system has this information, its identity selector can present the user with a visual representation of her available identities that meet these requirements. The user selects one of these (step 2), and the identity selector contacts the appropriate identity provider to get a token for this identity (step 3). Once it has the token, the browser or client sends it to the application (step 4), which verifies it, then uses the claims it contains (step 5).
在这个更完整的示例中，从用户访问应用程序开始。无论使用浏览器还是客户端联系，应用程序都会返回一个用于指出需要的哪种令牌（Token），令牌（Token）中应包含哪种类型的声明（Claims），以及它所信任的 标识提供程序（Identity Provider）（步骤1）。 和之前一样，在 基于声明的（Claims-Based）世界里，应用程序可以使用 WS-SecurityPolicy（通过SOAP请求）或者 HTML（通过HTTP请求）这种与供应商无关（Vendor-neutral）的方式，来描述这些需求。一旦用户的系统拥有了这个信息，身份选择器（Identity Selector）将可以通过可视化的方式向用户展示满足这些条件的可用身份（Identities）。用户将选择其中一个（步骤2），并且 身份选择器（Identity Selector）将会去联系合适的 标识提供程序（Identity Provider）来为这个 身份（Identity）获取令牌（Token）（步骤3）。一旦拥有了令牌，浏览器或客户端将会发送它到应用程序（步骤4），应用程序会验证它，然后在使用其中的声明（Claims）（步骤5）。
While claims-based identity does specify important aspects of these interactions, such as how tokens are requested from an STS, this approach explicitly omits defining other things. For example, the claims-based approach doesn’t mandate any particular format for tokens. It’s common today to use tokens defined using the XML-based Security Assertion Markup Language (SAML), but this isn’t required. Any token format that an application and an STS agree on can be used.
虽然，在 基于声明的标识（Claims-Based Identity） 中着重规范了这些交互方面，像是 如何从STS中请求令牌（Token），这种做法显然的忽略了定义其他事情。例如， 基于声明的（Claims-Based） 方法中 没有定义任何详细的令牌（Token）格式。如今，常用的方式是使用 基于XML的 安全断言标记语言（Security Assertion Markup Language，SAML）来定义令牌（Tokens），但这不一定是必要的。令牌（Token）格式是可以通过 应用程序和STS协商确定的。
“Geneva” 的角色
Making claims-based identity real requires several things. STSs must be available, or there will be no place to get tokens. An identity selector would also be nice to have, since without one, users are probably restricted to a single identity. And finally, developers will need to build claims-aware applications that know how to receive tokens and use the claims they contain. Rather than making every developer write this code from scratch, it would make sense to provide a standard library that any application could use.
制造 基于声明的标识（Claims-Based Identity） 需要几个东西。STS是必须可少的，否则将没有地方获得令牌（Token）。 身份选择器（Identity Selector）也应该拥有，如果没有，用户很可能会被限制使用单个身份（Identity）。最后，开发者也需要建立 具有 声明意识（Claims-aware）的应用程序，它知道如何接收令牌（Token）并使用其中的声明（Claims）。并不是每个开发者都是从零开始写代码，这里将提供一个标准类库，可以在任何应用程序中使用。
These three things are exactly what the “Geneva” Server, CardSpace “Geneva”, and the “Geneva” Framework provide. Figure 5 shows where each of these technologies fits.
这有三样东西，确切的说是 “Geneva” 服务器，CardSpace “Geneva”，和 “Geneva” Framework。图5 说明的它们 应在的位置。
![clip_image001[29]](http://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/5eb3a6f931da_A1/clip_image001%5B29%5D.png "clip_image001[29]")
Figure 5: The “Geneva” Server implements a Windows-based STS, CardSpace “Geneva” provides an identity selector for Windows clients, and the “Geneva” Framework is a standard library for creating claims-aware Windows applications.
图5： “Geneva” 服务器实现了基于Windows的STS，CardSpace“Geneva” 为Windows 客户端提供身份选择器，“Geneva” Framework 是一个标准类库，用来建立具有 声明意识（Claims-aware）的Windows应用程序。
This figure is a replica of Figure 4; the only difference is that the “Geneva” Server is shown as one of the STSs, CardSpace “Geneva” is shown as the identity selector, and the application is built using the “Geneva” Framework. All three technologies are described in more detail later in this overview, but it’s worth looking at the basics of each one here.
这个图是图4的副本，唯一的区别是 “Geneva“服务器显示在 STS 之中，CardSpace “Geneva” 显示在身份选择器（Identity Selector）上，还有 应用程序 使用 “Geneva” Framework 构建。三样技术的详细信息 稍后叙述，这里主要说明他们的基本功能。
The “Geneva” Server is the next release of Microsoft’s Active Directory Federation Services (AD FS). Don’t be misled by the word “federation” in the original name of this technology, however. While the “Geneva” Server does support identity federation, it also provides broad support for claims-based identity. For example, unlike its predecessor, the “Geneva” Server implements an STS that generates SAML tokens in response to WS-Trust requests. Also unlike AD FS, which supported only Web browsers, the “Geneva” Server supports both browsers and other clients, such as those built using Windows Communication Foundation (WCF). (In the jargon of identity, the “Geneva” Server supports both active and passive clients, while AD FS supported only passive clients.) Another important difference from the original AD FS is that the “Geneva” Server supports both WS-Federation and the SAML 2.0 protocol, letting it work in a broader range of environments.
“Geneva” 服务器 是 下一个版本的 Microsoft 的Active Directory Federation Services（AD FS）。但是，不要被这个技术原来的名字中的“联合（Federation）” 一词误导了。 虽然，“Geneva” 服务器 支持 身份联合（Identity Federation），也提供对 基于声明的标识（Claims-Based Identity） 的广泛支持。例如， 不像它的前身那样， “Geneva” 服务器 实现了STS，可以生成SAML令牌（Tokens）来响应 WS-Trust 的请求。 也不像 ADFS，仅仅支持Web浏览器，“Geneva”服务器 支持 浏览器和其他客户端，如那些使用 Windows Communication Foundation (WCF)构建的程序。（用 标识（Identity）的专业术语来说，“Geneva”服务器支持 主动（Active） 和被动（Passive）客户端，但ADFS仅支持被动（Passive）客户端。） 另一个和原来ADFS的巨大区别是，“Geneva”服务器支持 WS-Federation 和 SAML 2.0 协议，这可以让它工作在更加广泛的环境上。
The “Geneva” Server STS can potentially be used by any identity provider, whether it’s inside an organization, exposed on the Internet, or both. Yet it’s important to understand that using claims-based identity doesn’t require using the “Geneva” Server. As Figure 5 suggests, any STS from any vendor, or even a custom-built STS, can be used. Still, one of Microsoft’s primary goals in providing the “Geneva” Server is to make widely available a fully-featured STS built on AD DS. Until STSs are common, the benefits of claims-based identity are unlikely to materialize.
“Geneva”服务器 STS 可以被任何 标识提供程序（Identity Provider）使用，无论是在组织内部，还是暴露在互联网上的，还是两者都有的。然而要理解，使用 基于声明的标识（Claims-Based Identity） 并不一定需要使用“Geneva” 服务器。正如图5中预示的，任何STS，可以是来自不同的 提供商，甚至可以是 定制构建（Custom-Built） 的STS，也可以被使用。尽管如此，微软 提供 “Geneva” 服务器的主要目标之一是 在ADDS上构建 广泛可用的全功能STS。 直到 STS普遍存在，否则 基于声明的标识（Claims-Based Identity）的益处是无法显现出来的。
CardSpace “Geneva” is also the successor to an existing Microsoft technology, the original CardSpace. This identity selector can be used both with Web browsers, including Internet Explorer and Firefox, and with other Windows clients, such as WCF applications. And while an STS is fundamental to a claims-based world, using an identity selector isn’t required—claims-based identity can still work without one. Yet without CardSpace “Geneva” or a similar technology, users will have no consistent way to select which identity they wish to use. Even though an identity selector isn’t strictly required, it’s hard to imagine an effective claims-based world without one.
CardSpace “Geneva” 也是 微软现存技术 CardSpace 的继任者。这个身份选择器（Identity Selector）可以被 IE和Firefox 这样的浏览器使用，也可以是其他Windows客户端，如WCF程序。虽然 STS是 基于声明的（Claims-based）世界的基础，但使用 身份选择器（Identity Selector） 也不是必须的——没有它，基于声明的标识（Claims-Based Identity）仍能继续工作。 然而，没有了CardSpace “Geneva” 或者类似技术，用户将很难 使用直观的方式 来选择 希望使用的 身份（Identity）。 虽然 身份选择器（Identity Selector）并不是必须的，但是如果没有它，很难想象 在 基于声明的（Claims-Based） 世界 中的效率。
An important aspect of an identity selector is its user interface. Letting users select their identity in the same way for every application and every kind of client can greatly simplify their lives. Toward this end, CardSpace “Geneva” provides the standard screen shown in Figure 6.
身份选择器（Identity Selector） 一个重要方面就是它的界面（UI）。对于每个应用程序，使用同样的方式让用户选择他们的身份（Identity） 还可以 大大简化各种客户端的工作。下面， CardSpace “Geneva” 提供了一个标准界面 如图6中的样子。
![clip_image002[13]](http://images.cnblogs.com/cnblogs_com/GSonOVB/WindowsLiveWriter/5eb3a6f931da_A1/clip_image002%5B13%5D.png "clip_image002[13]")
Figure 6: CardSpace “Geneva” provides a common user interface for selecting identities, representing each identity with a card.
图6：CardSpace “Geneva” 提供一种统一的用户界面来选择身份，用卡片来表示每个身份。
Each identity is represented by a card (hence the name “CardSpace”). Each card is associated with a particular identity at some identity provider. Clicking on a card causes CardSpace “Geneva” to request a token for this identity from the associated identity provider, perhaps prompting the user for a password or something else to authenticate the request. While the software exchanges tokens containing claims, a user sees only this simpler metaphor of cards.
每个身份（Identity）都是用卡片来表示的（所以名字叫做“CardSpace”）。每个卡片关联某个识提供程序（Identity Provider）提供的特定标识（Identity）。 单击一个卡片，可以使CardSpace “Geneva” 去为这个身份请求令牌（Token），从关联的 识提供程序（Identity Provider）上，或许会提示输入用户密码或者其他什么东西 来认证请求。 虽然 软件交换包含声明（Claims）的令牌（Tokens），但用户看到的是这个简单的卡片。
The third component required to make claims-based identity a reality, at least for Windows applications, is the “Geneva” Framework. This library is a set of .NET Framework classes that implement basic functions, such as receiving a token, verifying its signature, accessing the claims it contains, and more. For situations where the “Geneva” Server STS isn’t sufficient, the “Geneva” Framework also provides support for building your own STS. One important example of this already exists: The “Geneva” Server itself is built on the “Geneva” Framework.
第三个用来使 构建 基于声明的标识（Claims-Based Identity） 成为现实的组件，至少是对Windows程序 是 “Geneva” Framework。 这个类库是一组.NET Framework 类，他们实现了基本功能，像是接收令牌（Token），验证签名，访问其中的声明（Claims）等等。 如果只有 “Geneva” 服务器 的STS ，那是不够的， “Geneva” Framework 也提供了 对 构建自己的STS支持。有个很好的例子存在： “Geneva” 服务器 自身 就是使用 “Geneva” Framework 建立的。
It’s important to realize that because all interaction is done in a standard way, none of these technologies specifically requires any of the others. The “Geneva” Server doesn’t require CardSpace “Geneva”, CardSpace “Geneva” doesn’t require the “Geneva” Server, and neither one requires applications to use the “Geneva” Framework. To CardSpace “Geneva”, for example, the “Geneva” Server looks like any other STS, with token requests sent using the standard WS-Trust protocol. Even though all of these technologies are from Microsoft, there are no proprietary links between them—all of the communication is based on industry standards. The goal is to make it easier to use claims-based identity both within the Windows world and across platforms from different vendors.
需要注意的是，所有的这些交互都是通过标准方式，没有哪种技术明确说明需要其他的。 “Geneva”服务器不需要 CardSpace “Geneva”，CardSpace “Geneva” 也不需要 “Geneva” 服务器， 不管哪一个都不需要“Genvea” Framework。 例如， 对于CardSpace “Geneva” ， “Geneva” 服务器看起来和其他STS 没有区别，通过 使用标准的 WS-Trust 协议 发送 令牌（Token）请求。 尽管 这些技术都来至微软，但他们之间没有专用的链接——所有的通讯都是基于工业标准。 目标是 让 使用 基于声明的标识（Claims-Based Identity）变的更简单，无论是 Windows平台还是 跨平台的不同供应商。
扫一扫
88
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
