代码改变世界

(翻译)《介绍 GENEVA Beta 1 白皮书》(1)

2009-06-03 00:50 by G yc {Son of VB.NET}, ... 阅读, ... 评论, 收藏, 编辑

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


介绍 “GENEVA”

概述 “GENEVA” 服务器, CARDSPACE “GENEVA”,和 “GENEVA” FRAMEWORK 。

UNDERSTANDING CLAIMS-BASED IDENTITY
了解 基于声明的标识(Claims-Based Identity)

今天,对于开发软件的人们,制作使用身份标识(Identity)的程序已经不是那么有趣了。首先,开发员需要为某个程序选择一个合适的 身份标识技术(Identity Technology)。如果可以通过不同的方式访问程序,如在一个组织里的访问,跨越不同组织访问,还有通过公共互联网的访问,一个 身份标识技术(Identity Technology)可能不够用——程序可能还需要支持多个可选的技术。然后,开发人员需要解决如何 寻找和保持 应用程序 每个用户的身份信息(Identity Information)。 应用程序将会直接从这些用户中获取一些信息,但也可能需要查找其他信息通过目录服务(directory service)或者其他地方。

比上面的还复杂的需求是,为什么不创建一个共用操作方法用来在每个相似的情况下获取身份标识(Identity)?或者制作程序寻找身份信息(Identity Information),为什么不确保这个一个方法可以让用户提供每个程序所需要的 身份信息(Identity Information)?

基于声明的标识(Claims-Based Identity) 实现了这两个目标。它提供一种通用的方式,让应用程序可以获取在组织内部的,在其他组织的,和在互联网上的用户 身份信息(Identity Information) 。 基于声明的(Claims-Based)方法也可以降低构建和管理程序的费用,同时也简化了开发人员的工作。

要制作 基于声明的标识(Claims-Based Identity) 需要开发人员理解如何和为什么 要创建 基于声明的应用程序(Claims-Based Applications) 。 同时,应用程序也需要依赖一些软件基础需求。本概述将描述基于声明的标识(Claims-Based Identity) 基本原理,然后看看微软即将推出的一组技术——“Geneva ”服务器,Windows CardSpace “Geneva” ,和 “Geneva” Framework——将有助这个成为现实。所有3个组件目前仍是测试阶段,所以,你应该知道在最终发布前可能会有变动。不过,这不是太早开始了解这一前景以及我们如何使用。

问题:在应用程序中使用标识(Identity)

有时候,使用标识(Identity)是很简单的。例如,想想Windows程序,它不需要了解太多关于它的用户,程序只能被单个组织内的用户访问。这个程序可以仅仅依赖 Kerberos ,和一部分 Active Directory Domain services (AD DS,就是大家知道的 “活动目录(AD)”),去来认证程序的用户并转发关于用户的基本信息。或者,假设你创建了一个程序,它可以让用户通过互联网访问。同样,常见处理标识的方法很简单:需要每个用户提供一个用户名和密码,然后从数据库中获取这个用户的信息。

然而,在这些简单的情况下也会很快的瘫痪掉。要是你需要了解每一个用户更多的信息,而不仅仅是一个用户名/口令 或 Kerberos ,该怎么办呢? 你的程序将需要从其它源那里获取信息,比如: ADDS 或者 应用程序自己持有的信息。或者,假设程序必须能让组织内部的雇员访问,还有 客户 可以通过 互联网访问,该怎么让程序同时支持Kerberos和基于用户名/密码 的登录?还有什么情况下,你想让从业务伙伴的用户访问这个组织不需要单独的登录操作?这种身份联合(Identity Federation)不能很好的使用 Kerberos 或 用户名/密码,或者其他的登录方式。

合理的解决方法是 有一个获取标识(Identity)的方法,用于所有这些情况。为了使其有效,这个方法必须给是基于跨平台互操作和组织界限并被广泛认可的工业标准。但是,仅仅是标准还是不够的。解决方案也需要多个产品供应商的产品中广泛实施,并且简化开发人员的使用。这种统一,得到广泛支持的方法正是 基于声明的标识(Claims-Based Identity) 所要提供的方法。

解决方案:基于声明的标识(Claims-Based Identity)

基于声明的标识(Claims-Based Identity)是个简单的思想,建立在少数的几个概念上,如:声明(Claims),令牌(Tokens),标识提供程序(Identity Provider)等。本节将介绍这种技术的基础,首先看看这些基本概念。

但在开始说明之前,有个一点要说明。这篇文章专注于过程,使用技术描述这里可能需要很多,像是如不同企业间的商业协议等。技术的挑战是必不可少的,但并不是全部。

 

创建声明(Claim)

什么是标识(Identity)?在现实世界中,这个问题很难回答——讨论会很快的变成理论上的。然而,在数字世界里,答案很简单:一个数字标识(Digital Identity)是关于某人或某物的一组信息。任何实体都有数字标识,包括计算机和应用程序,以及我们最关心的识别(Identifying)使用者。所以,本概述中的标识将指为“用户”。

当数字标识(Digital Identity)跨网络传输时,它仅仅是一堆字节。通常情况下,它包含了标识信息(Identity Information),像是安全令牌(Security Token) 或者 只是 令牌(Token)。在 基于声明的(Claims-Based)世界里,一个 令牌(Token)包含一个或多个声明(Claims),每一个都包含了用于识别(identifies) 用户的一点信息。图1显示了它的样子。

clip_image001

图1:一个令牌(Token)包含关于用户的声明(Claims),和用于验证颁发者的数字签名。

声明(Claims)可以描述关于的用户几乎全部信息。例如,前面的实例中,在令牌(Token)中包含了 用户的名字,一个她所属组的标记(identifier)和 她的年龄 的3个声明。其它的令牌(Token)也可能根据需要包含额外的他声明(Claims)。为了验证令牌的来源和避免篡改,令牌的颁发者(Token's Issuer)将在建立令牌(Token)的时候使用数字签名。像图1中显示的,令牌(Token)中携带了一个签名。

但是,谁发布令牌(Token)?在基于声明的(Claims-based)世界中,令牌(Token)通过像是 安全令牌服务(Security Token Service,STS)这样的软件创建。图2说明这个过程。

clip_image002

图2:用户从 安全令牌服务(STS)获取包含一组声明(Claims)的令牌(Token)。

 

通常情况下,应用程序(像是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 Provider) 可以有多种提供形式。例如,如果使用企业内部网络上的STS颁发令牌的话, 标识提供程序(Identity Provider) 是你的公司的。或者,如果使用在互联网上 微软的Windows Live ID 服务提供STS 发布令牌,那么 微软服务将作为标识提供程序(Identity Provider) 。甚至,可以方便的将它作为自己的标识提供程序(Identity Provider) ,这将在稍后将会说明。

无论使用哪种 标识提供程序(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)可能包含各种信息。像图1中显示的,一个声明(Claim)可能包含传统信息,像是用户的名字和所属的组织小组。或者其它有用信息,如她的住址,或者其他描述信息,如她的年龄。声明(Claim)也可以用来确定(Identify)用户角色可以做什么,或者提供更多信息,应用程序可以使用它来做访问控制。 声明(Claim)也可以用来明确的指出用户做事的权利,如访问文件,或是限制某些权利,比如,设置雇员的消费额度。因为应用程序可以从令牌(Token)中获取它所需要的 身份信息(Identity Information),所以,基于声明的标识(Claims-Based Identity)可以使 应用程序开发人员的工作变得简单。

这种方法也来带一个好处:它可以避免开发人员去做认证(Authenticating)用户的任务。应用程序所需要做的是确认 创建 用户所使用令牌(Token)的 STS 是应用程序所信任的。用户如何向STS证明自己的身份(Identity)——通过 密码, 数字签名或者其他什么东西,这将不是应用程序的问题了。这允许应用程序部署在不同的环境下保持不变,大大改善了今天的局面。

 

 

Using Claims
使用声明(Claims)

声明(Claims)、令牌(Tokens)、标识提供程序(Identity Provider),还有 令牌安全服务(STS) 都是创建 基于声明的标识(Claims-Based Identity)的必要基本功能。然而,这都只是手段。真正的目标是帮助用户向应用程序出示她的数字身份(Digital Identity),然后让应用程序使用这个信息决定她能做什么。 图3 显示 这个是如何发生的简单图例。

clip_image001[27]

图3:浏览器或者其他客户端从STS获取令牌(Token),然后 出示这个令牌 并且 其中包含 到应用程序的声明(Claims)。

 

如图所示,浏览器或客户端 代表用户 向拥有某个标识提供程序(Identity Provider)的STS 请求用于特定程序的令牌(Token)(步骤1)。一旦获得这个令牌(Token),浏览器或客户端将发送它到应用程序(步骤2),应用程序将尝试验证它的签名。在核查工作中,应用程序知道了哪个 识提供程序(Identity Provider)的 哪个 STS发布的令牌(Token)。如果应用程序信任这个标识提供程序(Identity Provider),它将假设令牌中的声明(Claims)是正确的并使用他们决定用户可以做什么(步骤3)。

例如,如果令牌(Token)中包含用户的名字, 应用程序将会假设用户她是声明中的那个人。由于用户需要通过认证(Authenticate)才能获取到她自己的令牌(Token),如前所述,所以应用程序不需要再次认证她。事实上,正因为依赖令牌(Token)中的声明(Claims),所以 应用程序有时也被称作 依赖方(Relying Party)。

虽然没有显示在图上,但是在发生这些事情之前还有一个必须要做的事:管理员必须配置STS来为应用程序和用户发布正确(Right)的声明(Claims)。如果不这么做,没有办法来使STS来创建包含应用程序所需要声明(Claims)的令牌(Token)。虽然这样做似乎是重担,但事实是这一信息也必须配置到 非基于声明的(Non-Claims-based)世界。最大区别在于,现在通过STS所有需要的声明(Claims)都集中在一起,而不是分散在各个系统中。

在图3中隐含这样的一个假设,用户她对所有应用程序都只用一个数字身份(Digital Identity)。虽然,事实是她可能希望向不通的程序发送不同的身份信息(Identity Information)。想想这个在现实世界中怎么做的:你向边防出示护照(Passport),但是给你颁发驾照(Driver's License)的是交通警察。绝不接受其他的身份(Identity),因为不同的情况需要出示来至不同源的不同的信息。护照是由联邦政府(national governments)部门颁发的,而驾照则是由本地的部门颁发的,如州府。在数字世界中模拟这种情况就是 依赖 不同的 标识提供程序(Identity Provider),每个可用的STS将发布包含 合适声明(Claims)的令牌(Token)。这些令牌(Token)中的声明(Claims)都各不相同,就像你护照中的信息和你的驾照的不同。

如果我们有多个数字身份(Digital Identities),并且我们使用一种统一方式来选择 每次我们要访问的特定程序时,所使用的身份。换句话说,我们需要一个 身份选择器(Identity Selector)。图4 显示了这个组件合适的位置。

clip_image002[11]

图4:身份选择器(Identity Selector)为用户 提供了一种统一方式,来选择希望向到程序出示的身份。

在这个更完整的示例中,从用户访问应用程序开始。无论使用浏览器还是客户端联系,应用程序都会返回一个用于指出需要的哪种令牌(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)。

虽然,在 基于声明的标识(Claims-Based Identity) 中着重规范了这些交互方面,像是 如何从STS中请求令牌(Token),这种做法显然的忽略了定义其他事情。例如, 基于声明的(Claims-Based) 方法中 没有定义任何详细的令牌(Token)格式。如今,常用的方式是使用 基于XML的 安全断言标记语言(Security Assertion Markup Language,SAML)来定义令牌(Tokens),但这不一定是必要的。令牌(Token)格式是可以通过 应用程序和STS协商确定的。

 

The Role of “Geneva”
“Geneva” 的角色

制造 基于声明的标识(Claims-Based Identity) 需要几个东西。STS是必须可少的,否则将没有地方获得令牌(Token)。 身份选择器(Identity Selector)也应该拥有,如果没有,用户很可能会被限制使用单个身份(Identity)。最后,开发者也需要建立 具有 声明意识(Claims-aware)的应用程序,它知道如何接收令牌(Token)并使用其中的声明(Claims)。并不是每个开发者都是从零开始写代码,这里将提供一个标准类库,可以在任何应用程序中使用。

这有三样东西,确切的说是 “Geneva” 服务器,CardSpace “Geneva”,和 “Geneva” Framework。图5 说明的它们 应在的位置。

clip_image001[29]

图5: “Geneva” 服务器实现了基于Windows的STS,CardSpace“Geneva” 为Windows 客户端提供身份选择器,“Geneva” Framework 是一个标准类库,用来建立具有 声明意识(Claims-aware)的Windows应用程序。

这个图是图4的副本,唯一的区别是 “Geneva“服务器显示在 STS 之中,CardSpace “Geneva” 显示在身份选择器(Identity Selector)上,还有 应用程序 使用 “Geneva” Framework 构建。三样技术的详细信息 稍后叙述,这里主要说明他们的基本功能。

“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 协议,这可以让它工作在更加广泛的环境上。

“Geneva”服务器 STS 可以被任何 标识提供程序(Identity Provider)使用,无论是在组织内部,还是暴露在互联网上的,还是两者都有的。然而要理解,使用 基于声明的标识(Claims-Based Identity) 并不一定需要使用“Geneva” 服务器。正如图5中预示的,任何STS,可以是来自不同的 提供商,甚至可以是 定制构建(Custom-Built) 的STS,也可以被使用。尽管如此,微软 提供 “Geneva” 服务器的主要目标之一是 在ADDS上构建 广泛可用的全功能STS。 直到 STS普遍存在,否则 基于声明的标识(Claims-Based Identity)的益处是无法显现出来的。

CardSpace “Geneva” 也是 微软现存技术 CardSpace 的继任者。这个身份选择器(Identity Selector)可以被 IE和Firefox 这样的浏览器使用,也可以是其他Windows客户端,如WCF程序。虽然 STS是 基于声明的(Claims-based)世界的基础,但使用 身份选择器(Identity Selector) 也不是必须的——没有它,基于声明的标识(Claims-Based Identity)仍能继续工作。 然而,没有了CardSpace “Geneva” 或者类似技术,用户将很难 使用直观的方式 来选择 希望使用的 身份(Identity)。 虽然 身份选择器(Identity Selector)并不是必须的,但是如果没有它,很难想象 在 基于声明的(Claims-Based) 世界 中的效率。

身份选择器(Identity Selector) 一个重要方面就是它的界面(UI)。对于每个应用程序,使用同样的方式让用户选择他们的身份(Identity) 还可以 大大简化各种客户端的工作。下面, CardSpace “Geneva” 提供了一个标准界面 如图6中的样子。

clip_image002[13]

图6:CardSpace “Geneva” 提供一种统一的用户界面来选择身份,用卡片来表示每个身份。

 

每个身份(Identity)都是用卡片来表示的(所以名字叫做“CardSpace”)。每个卡片关联某个识提供程序(Identity Provider)提供的特定标识(Identity)。 单击一个卡片,可以使CardSpace “Geneva” 去为这个身份请求令牌(Token),从关联的 识提供程序(Identity Provider)上,或许会提示输入用户密码或者其他什么东西 来认证请求。 虽然 软件交换包含声明(Claims)的令牌(Tokens),但用户看到的是这个简单的卡片。

第三个用来使 构建 基于声明的标识(Claims-Based Identity) 成为现实的组件,至少是对Windows程序 是 “Geneva” Framework。 这个类库是一组.NET Framework 类,他们实现了基本功能,像是接收令牌(Token),验证签名,访问其中的声明(Claims)等等。 如果只有 “Geneva” 服务器 的STS ,那是不够的, “Geneva” Framework 也提供了 对 构建自己的STS支持。有个很好的例子存在: “Geneva” 服务器 自身 就是使用 “Geneva” Framework 建立的。

需要注意的是,所有的这些交互都是通过标准方式,没有哪种技术明确说明需要其他的。 “Geneva”服务器不需要 CardSpace “Geneva”,CardSpace “Geneva” 也不需要 “Geneva” 服务器, 不管哪一个都不需要“Genvea” Framework。 例如, 对于CardSpace “Geneva” , “Geneva” 服务器看起来和其他STS 没有区别,通过 使用标准的 WS-Trust 协议 发送 令牌(Token)请求。 尽管 这些技术都来至微软,但他们之间没有专用的链接——所有的通讯都是基于工业标准。 目标是 让 使用 基于声明的标识(Claims-Based Identity)变的更简单,无论是 Windows平台还是 跨平台的不同供应商。