级别： 初级 Arnab Dasgupta (arnabdasgupta@in.ibm.com), 资深软件工程师, IBM India Software Lab
2005 年 5 月 30 日
为了缩短分布式客户机/服务器应用程序中事务的执行时间，您可以对一个事务所涉及的实体之间的授权信息流加以提炼。在本文中，您将学习如何使用可插入授权模块（Pluggable Authorization Module，PLAM）来减少客户机和服务器之间传递的冗余授权信息。PLAM 是一个 DCE 风格的授权框架模型，它可以缩短请求的往返周期。
早期的产品，例如 IBM Distributed Computing Environment（DCE），提供了安全的分布式事务，但是它们也采用了一些负载很重的服务，这可以消耗很多系统资源，非常难以管理。知道这个问题之后，管理员通常就希望将 DCE 服务（不包括 RPC）与文件服务（例如 DFS）分隔开来。由于这个原因，有一些第三方的应用程序已经被替换掉了，而且有几个新的组件正在进行开发，用来集成这些新的服务。
可插入授权模块（PLAM）是一个新开发的授权模型，负责进行有效的缓存和分布式事务所涉及的不同实体之间的授权信息流。它设计的另外一个目的是，让这些信息对于服务组件高度可用。
PLAM 的进化
PLAM 背后的思想就是 DCE 替换策略的一部分。IBM Pittsburgh Lab（与位于 Pune 的 IBM India Software Lab 合作）开始了两个独立的项目：
-
SARPC（StandAlone RPC）是一种负责将 DCE Security 和 Cell Directory 服务从 DCE RPC 中隔离出来的机制。SARPC 与 DCE RPC 的代码基础是相同的，但是它使用 Kerberos v5 协议提供了很好的安全性；它还通过 ANS（这是一个基于文件/DNS 的资源位置服务，是 ADFS 项目的一部分）提供资源位置服务。SARPC 1.0 是在 2005 年 1 月发布的。
-
ADFS （Advanced Distributed File System）项目设计用来帮助将 DCE Security 和 Cell Directory Services 从 DFS 中隔离出来。作为一种替换，ADFS 最初采用了 Kerberos v5 协议（用于认证）、一个 GroupServer（用于授权）和一个基于文件/DNS 的资源位置服务（称为 ANS）。ADFS 现在使用 SARPC 进行通信，而不使用 DCE RPC。这个项目主要的工作是，像在 DFS 中一样在分布式文件服务架构上集成新的安全基础设施。
PLAM 框架源自于 ADFS 项目。印度的 ADFS 组提供了一些概念来增强 SARPC 在线路上的性能；他们还提供了 PLAM 的一个伪实现，并将其集成到 SARPC 代码中，仿佛它们已经存在了一样。后来，SARPC 小组实现了真正的 PLAM 源代码，并将之集成到了 SARPC 中。目前的版本是 SARPC 1.0。
将 PLAM 集成到 SARPC 中需要 ADFS 的 GroupServer，因为用户的网络组成员信息是由 GroupServer 提供的。PLAM/SARPC 现在可以支持 AIX®、Solaris 和 Windows® 平台，SARPC 的下一个发行版将会支持 Linux™ 平台。
现在让我们来复习一下关于分布式环境中授权的一些基础知识，以及 PLAM 架构的一些术语。
授权的基础知识
授权 是在分布式环境中为哪些用户或应用程序建立使用特定资源（可以是服务或文件系统中的数据）的能力的过程。这种系统在底层会执行一个认证操作，在这个过程中，用户或应用程序需要向可信的认证服务组件验证自己的身份，之后获得一个服务令牌以取得对资源管理器的已认证访问权限。
简单来说，要在共享环境中获得对其他资源的访问权限，请求实体必须回答目标资源管理程序的两个问题：
-
您是自己所宣称的那个人吗（是否已通过 认证）？
-
您被允许可以对共享对象执行哪些操作（是否被 授权 来访问某个资源）？
认证是以 服务令牌（service ticket） 的形式提供的，这是由域中的一个可信认证服务发出的，并使用目标资源管理器的密钥进行了加密。这种令牌可以提供给任何这样的实体，即它可以通过使用在认证服务中注册的加密密码登录到域中，从而向认证服务证明自己的身份。
授权是以组成员关系的形式提供的。这些信息由域中的另外一个可信服务器进行保存，它可以对请求实体提供成员关系的证明信息。
理想情况下，授权信息应该以请求实体所属于的网络组列表的格式来提供；否则，就很难根据数百个实体名来维护对每个共享资源的访问控制列表（ACL）。要增强 ACL 的可管理能力，必须对实体进行分组，然后为这些组提供对不同共享资源的访问权限。
授权所涉及的实体
在基本的分布式环境中，对于资源（文件、打印机、数据库，等等）的访问是通过资源管理器（应用程序服务器）进行管理的。当客户机试图对某个资源（不管是应用程序服务还是它所维护的数据）进行操作时，资源管理器就会对这个客户机的身份（展示为 特权属性 或 PA）进行检查，并将其与该资源相关的 控制属性（通常是一个 ACL）进行比较。然后决定接受还是拒绝这个请求。
PA 是由一个可信系统组件向客户机以 特权属性证书（PAC）证明的形式颁发的。PAC 被安全地嵌入到认证服务令牌（这是由 认证服务提供方 产生并颁发的，它也是分布式系统中可信计算基础的一部分）中，每当客户机被要求获得对某个特定对象的访问权限时，它们就会一起在线路上传输。
图 1 阐述了在分布式授权过程中所涉及的不同实体。
图 1. 分布式授权过程中的实体
原始的 DCE pull 模型
DCE 通过一个认证 RPC 机制在客户机和服务器之间提供了一个安全的通信通道。
（通过一个适当的 DCE API 调用）向目标服务器发起一个已认证的 RPC 的职责在于客户机程序。服务器的 RPC 运行库然后负责通过一个 WHO-ARE-YOU 回调机制（也称为 WAY Challenge）从客户机中获得请求用户的信任证书（例如 Kerberos v5 Service Ticket、PAC）；然后服务器对请求进行授权。
服务器的 RPC 运行库也会对用户的信任证书信息基于会话进行缓存，这样就不需要对来自相同客户机会话的每个其他 RPC 都重复进行 WAY Challenge 了。图 2 阐述了 DCE 的安全系统。
图 2. DCE 安全系统架构
为什么要构建一个新框架？
通过从分布式应用程序实现 DCE 安全服务，新被替换的应用程序和服务必须要满足分布式环境中的很多安全性要求，包括以下内容：
-
通过 Kerberos v5 Protocol 提供认证机制
-
通过远程过程调用提供一个安全通信通道
-
在可信服务器上存储实体的授权信息
然而，DCE 冗余授权信息这一基本的问题在线路中依然存在：同一用户的多次登录会导致向资源管理程序发送多份该用户的 PAC 信息。例如，如果 Tom 访问服务器 T，假设他是从机器 A、B 和 C 上多次登录的，或者是从机器 A 上登录了三次，尽管这些登录过程中的组成员关系都没有发生变化，但是在这些会话的初始访问请求过程中，会有 3 个相同的 PAC 被发送到服务器 T 上。图 3 阐述了这种现象。
图 3. DCE 授权中冗余的 PAC 流
图 3 显示了当一个用户从 3 个不同的终端登录到 DCE 单元时：
-
DCE Registry Server 以 PAC 的格式为用户提供他的网络身份标识。
-
在会话 1 中，用户发送一个对 DCE 应用服务器的资源请求。服务器获取该用户完整的 PAC 结构进行授权。
-
在会话 2 中，该用户再次发送一个对 DCE 应用服务器的资源请求，这会再次获取该用户完整的 PAC 结构。由于该用户的网络组成员关系在这两次登录之间并没有发生改变，因此服务器所获取的 PAC 结构就与会话 1 中的完全相同。
-
服务器在会话 3 中再次为资源请求获取组信息。因此，同一个用户在使用相同的证书多次访问相同的服务器时，线路中存在冗余信息。
当很多用户与 Tom 一样进行操作时，就会发生以下问题：
-
由于巨大的信息处理开销，请求响应的时间会变长。如果 Tom 属于一个大型的网络组，那么 PAC 结构就会同时增长，对整个结构的解密也就会在服务器上花费更长的时间。
-
网络会由于这些冗余的 PAC 而产生拥塞。
假设在一天工作时间的早些时候有 2,000 个用户登录到系统中，而且每个用户都在相同的服务器上有多个会话，那是什么情况？！
因此，我们怎样来解决这个冗余 PAC 所产生的恶梦呢？
plug-n-play 方法
本文中所提倡的解决方案是，在客户机和服务器的运行库之中插入一个授权模块，用于处理应用程序的授权要求，而不需要客户机和服务器的干涉。而且，为了最小化线路上巨大的 PAC 结构的数据流，我们需要开发一个新的数据结构，这个数据结构中只包含那些用来安全并惟一标识请求实体的组成员身份所需要的信息。
实现这种解决方案的一个快速的方法是，让一个基于 PKI 的证书权威为请求客户机颁发一个 PAC 身份标识证明。然后客户机就可以在请求资源访问权限时为目标应用服务器生成这个身份标识符（identifier）（而不是更大的 PAC 结构）。
这个身份标识符与 PAC 相比非常小，它可以通过附加一个超时时间来区分类似的会话（用户的登录会话不同，但组成员信息相同）。标识符中记录了请求实体的名字，这样如果有任何非法的使用，目标资源管理器就可以立即判断出来。图 4 显示了 PLAM 是如何消除这种冗余的。
图 4. 使用 PLAM 消除线路中的冗余
在图 4 中，这个用户再次从 3 个不同的终端中进行登录：
-
ADFS GroupServer 以 PAC 和 PAC 标识符的格式为用户提供了他的网络标识。
-
在会话 1 中，用户向资源管理器发送一个资源请求。服务器请求用户的 PAC ID。由于 PAC 现在还不在服务器的缓存中，因此在对传来的 PAC ID 进行验证的同时，服务器还会获取该用户的 PAC（其中包含了组成员信息）进行授权。
-
在会话 2 和会话 3 中，用户的资源请求应该只需要向服务器发送这个 PAC ID 即可，因为 PAC 的相应版本（5.0）已经在服务器的缓存中了，另外还附加了一个超时时间。
由于 PAC ID 与 PAC 相比非常小，因此线路的拥塞就会得到缓解，Tom 和他的 2,000 个朋友（他们具有强烈的要求，需要从多台机器上进行登录）就不会导致系统因为负载过重而崩溃；这种方法显然可以帮助消除我们在 DCE 授权框架中所看到的冗余问题。
现在让我们来了解一下这个新框架的一些组件。
PLAM 内幕
我们来看一下这个新框架的一些元素：
- 设计原则
- 模型的优点
- PAC 标识符
- 组件是如何工作的
- 缓存的考虑
- 网络拥塞
设计原则
本文提议的模块在设计时遵守以下原则：
-
任何远程过程调用都是根据用户的请求进行操作的。
-
实现每个请求与用户授权信息的透明关联是底层的职责。
我们希望能够在目标资源上或目标资源附近缓存动态的或特定于域的用户属性列表的拷贝。每当需要使用这些信息来确定授权决策时，都可以从客户机或通过查找缓存来获取这些信息。
而且，在这个模型中，授权数据已经与认证数据分隔开了，这样，授权数据就应该不用嵌入认证令牌中了。我们应该为应用服务器提供一个单独的缓存和流转机制。
模型的优点
这个模型的优点如下：
-
整个框架的通用性非常好，因此任何使用 RPC 或 socket 进行通信的第三方应用程序都可以使用这个安全层来通过回调传输自己日益增长的授权数据。（应用程序也可以选择使用其他不同的参数集来惟一标识一个用户的 PAC ID。）
-
这个框架提供了一种一致的方法在用户空间的应用程序和内核模块之间传输授权数据。因此，分布式客户机/服务器应用程序，例如 NFS、DFS™、AFS®、TXSeries®、Encina®、MQSeries® 以及类似的程序，都仅需稍加移植就可以使用这种框架。
-
这个模型将篡改授权数据的风险降至了最低，因此服务器不用花费大量的时间来验证数据了。授权数据是由那些属于系统中可信计算基础的服务器颁发的，因此在它所管理的域中可以认为是安全的。
-
由于 PAC 标识符的采用，在线路中传递的实际成员信息已经在一个很广泛的范围内被最小化了。这减少了由于获取用户的 PAC 而产生的冗余报文而会导致网络拥塞的开销。
PAC 标识符
PLAM 需要一个已精简的 PAC 结构，称为 特权属性证书标识符（Privilege Attribute Certificate Identifier）。这个标识符允许对 PLAM 的服务器运行库中的授权信息进行有效的缓存，从而提供高可用性；它还可以降低线路中充斥的授权信息对网络带宽的消耗。这个结构如下：
PAC-ID: {User, Realm, Version, Expiry, Signature}
Realm 代表用户的本地域，就是最初创建用户帐户的地方。这些信息在访问属于一个外部域的资源时是必需的，因此用户的命名空间要求是惟一的。
Version 代表用户组列表的版本。PAC 版本应该由颁发证书的权威机构进行维护；当用户组的成员关系发生变化时，版本也应该变化。因此，在任何时候，相同的用户在不同的机器上登录会得到相同的版本号，但是超期时间不同。
Expiry 是指这个 PAC ID 要失效的时间。
Signature 是指 User, Realm, Version, Expiry 的校验和，它使用颁发证书的权威在 PKI 框架中的私钥进行了加密。这个私钥被安全地保存在证书颁发权威中，相应的公钥可以公开发布给应用服务器，这样，已修改的 PAC 证书就会被拒绝，只有可信的用户才能获得授权的访问权限。
框架概述
PLAM 中的新授权模型可以集成到通信层（RPC/Socket）中，从而将授权信息安全地传输给目标资源管理器。它位于应用程序和网络层之间，可以通过一组 API 简化对资源提供方缓存仓库的访问。
PLAM 中的内存缓存仓库是维护在应用服务器的运行库上的，并且可以使为做出授权决策，请求用户的组成员关系信息需要流经线路的次数最少。当新用户开始访问采用 PLAM 的应用服务器时，这个仓库会不断增加；这可以使用一个静态的期限和一个上限进行限制。
客户机和服务器之间的安全通信会话是通过从发起主机上获取请求者（用户和机器）的 PAC 标识符开始的。这个回调也会与 PLAM 在客户机的运行库中进行交互，从而获取 PAC 标识符；这与从用户的信任证书缓存中获取认证服务令牌不同。
PAC ID 签名是由资源管理器进行验证的；PAC 版本是通过一个活动的 PAC ID 进行标识的。如果在 PLAM 的内存缓存中找到了组列表对应用户的 PAC 的版本，那么这个用户就会根据 ACL 的限制对所请求的对象进行授权。
缓存“没有命中”会导致回调客户机来检索用户的组列表（格式是 PAC）。结果信息然后会由资源管理器进行缓存，并在相同用户再次请求时直接使用。
图 5 给出了 PLAM/SARPC 的安全架构。
图 5. PLAM/SARPC 安全架构
注意，在图 5 中，SARPC Runtime 是 DCE-RPC 模块的一个直接派生物，这是作为 DCE 替换策略开发的一个产品。Group Server 是基于 PKI 的认证权威，它替代了 DCE Registry Service。
有效的缓存
在 DCE 中，即使在不同会话和机器中为一个特定的用户使用的是包含类似组成员信息的 PAC，在服务器的运行库中也会缓存冗余的授权信息。这种冗余是由于 PAC 是嵌入在服务令牌中并且作为一个安全实体在客户机与服务器之间进行流转而引起的。因此，服务器上的每次缓存缺页都会触发一个 RPC 回调，它会获取整个完整的用户证书（STKT + PAC）。
PLAM 使用了一种不同的缓存模型，它更加有效，原因如下：
- Kerberos 所提供的服务令牌与已认证的特权属分离
- PAC 证书的使用
- GroupServer 所使用的 PAC 版本机制
PLAM 在自己的仓库中缓存的是用户 PAC 的不同版本的单个只读拷贝。如果在不同的通信会话中（以及在机器边界之外）使用的是用户属性列表的相同版本，那么目标管理器只会为这个版本缓存一个拷贝备以后引用。与 DCE 相比，这可以降低 PLAM 中缓存的开销和内存的过渡使用。
我们假设 Bob 已经从 10 台不同的机器上登录到系统中，或者从一台机器上登录了 10 次，并且已经与目标 Resource Manager T 建立了等量的会话。如果 Bob 在所有的会话中接收到的 PAC 的版本都是 8.000（因为当他在这些机器上登录时，他所属的网络组在 GroupServer 中并没有发生变化），那么目标服务器 T 上的 PLAM 运行库只在第一次会话中缓存一次 Bob 的 PAC 的 8.000 版本；其余的 9 个会话并不需要将自己的 PAC 发送给 T。
减少网络拥塞
采用这种新架构，客户机到服务器之间的第一个安全授权实体是 PAC ID。如果标识符中使用的 PAC 版本早已在采用 PLAM 的服务器上进行缓存了，那么就会直接建立这个会话，而不需要从发起主机上检索 PAC。这减少了很多网络开销，因为 PAC ID 的大小要比 PAC（其中嵌入了用户的组成员信息，随着成员关系扩展到网络中的其他组中，这会变得更大）小很多。
现在，一个特定版本的 PAC 只会向目标资源管理器发送一次；相同用户的其他会话可以通过发送 PAC ID 来建立自己的权威。
结束语
当您移植通用的分布式应用程序时，请记住：
-
颁发证书的权威应该在自己的仓库中为每个用户维护一个版本号。每次用户被加入或从一个网络组中删除时，就应该增加这个版本号。然后就可以使用这个版本号来构建 授权标识符 了。颁发证书的权威并没有必要一定基于公钥基础设施。共享密钥基础设施也可以用来提供 PAC 标识符。
-
在客户机和服务器端进行缓存可以在磁盘或内存中进行，这可以根据系统中所生成的负载的类型来决定。
随着对现有模型的持续改进，PLAM 还将对 PAC 标识符结构进行扩充，从而在整个架构中包含一个基于 IP 地址的 ACL。ADFS GroupServer 已经提供了这种支持，在 SARPC 中也实现了这种逻辑。
参考资料
关于作者  | 
| | 从位于印度乌兰巴托的 National Institute of Technology 获得计算机科学与工程的学士学位之后，Arnab Dasgupta 就开始在印度的 IBM Software Lab 工作了，他主要研究基于 DCE 和 DFS 之类分布式技术的文件服务。目前，他参与了在分布式客户机/服务器计算环境中使用 Kerberos 和 PKI 来增加数据安全性的工作，从而确保提高整个系统的性能。您可以通过 arnabdasgupta@in.ibm.com 与 Arnab 联系。 |
对本文的评价
| 
