DCOM实现分布式应用（四）
DCOM实现分布式应用（四） (上一篇)
DCOM实现分布式应用（四）安全性使用网络来将应用系统分布化是一个挑战，这不仅是因为带宽的物理限制以及一些潜在的问题，而且也由于它产生一些诸如关系到客户间、组件间以及客户和组件之间的安全问题。因为现在的许多操作可以被网络中的任何一个人访问，所以对这些操作的访问应该被限制在一个高级别上。
如果分布式开发平台没有提供安全支持，那么每一个分布式应用就必需完成自己的安全机制。一种典型的方法是用某种登录的方法要求用户通过用户名及密码的检测，这些一般来说都是被加密了的。应用系统将通过用户数据库或者有关目录来确认以上用户身分，并返回动态的标识符以便用户以后用来进行方法调用。以后每次涉及到调用有安全检查的方法时，用户都需要通过这种安全认证。每个应用系统都要存储和管理许多用户名和密码，防止用户进行未授权的访问，管理密码的改动以及处理在网络上传递密码而带来的危险。 因此分布式平台必需提供一个安全性框架来确切地区分不同的用户或者不同组的用户以便系统或应用有办法知道谁将对某组件进行操作。DCOM使用了Windows NT提供的扩展的安全框架。Windows NT提供了一套稳固的内建式安全模块，它用来提供从传统的信用领域的安全模式到非集中管理模式的复杂的身份确认和鉴定机制，极大地扩展了公钥式安全机制。安全性框架的中心部分是一个用户目录，它存储着用来确认用户凭据（用户名、密码、公钥）的必要信息。大多数并非基于Windows NT平台的系统提供了相似或相同的扩展机制，我们可以使用这种机制而不用管此平台上用的是哪种安全模块。大多数DCOM的UNIX版本提供了同Windows NT平台相容的安全模块。
安全性设置 DCOM无需在客户端和组件上进行任何专门为安全性而做的编码和设计工作就可以为分布式应用系统提供安全性保障。就象DCOM编程模型屏蔽了组件的位置一样，它也屏蔽了组件的安全性需求。在无需考虑安全性的单机环境下工作的二进制代码能够在分布式环境下以一种安全的方式工作。 DCOM通过让开发者和管理员为每个组件设置安全性环境而使安全性透明。就象Windows NT允许管理员为文件和目录设置访问控制列表（ACLs）一样，DCOM将组件的访问控制列表存储起来。这些列表清楚地指出了哪些用户或用户组有权访问某一类的组件。使用DCOM的设置工具（DCOMCNFG）或者在编程中使用Windows NT的registry以及Win32的安全函数可以很简单地设置这些列表。 只要一个客户进程调用一个方法或者创建某个组件的实例，DCOM就可以获得使用当前进程（实际上是当前正在执行的线程）的用户的当前用户名。Windows NT确保这个用户的凭据是可靠的，然后DCOM将用户名正在运行组件的机器或进程。然后组件上的DCOM用自己设置的鉴定机制再一次检查用户名，并在访问控制列表中查找组件（实际上是查找包含此组件的进程中运行的第一个组件）。如果此列表中不包括此用户（既不是直接在此表中又不是某用户组的一员），DCOM就在组件被激活前拒绝此次调用。这种安全性机制对用户和组件都完全是透明的，而且是高度优化的。它基于Windows NT的安全框架，而此框架是Windows NT操作系统中最经常被使用（也是最完美的！）的部分，对每一个对文件或者诸如一个事件或信号的同步线程的访问都需要经过相同的访问检查。Windows NT能够和同类的操作系统以及网络操作系统竞争并超过它们的事实可以显示出这种安全性机制是多么有效。
图13 安全性设置
DCOM提供了一个非常有效的缺省的安全性机制，它使开发员能够在无需但心任何安全性问题的情况下开发出安全的分布式应用。
对安全性的编程控制对某些应用系统来说，仅仅是组件级的访问控制列表是不够的，因为一个组件中的某些方法是只能被特定的用户访问的。
例子：一个商务结算组件可以有一个方法用来登录新事务，以及另一个方法用来获得已经存在的事务。仅仅只有财务组（“Accounting”用户组）的成员才能够添加新事务，同时仅仅只有高级管理人员（“Upper Management”用户组）才能查看事务。
正如上一部分所说，应用系统能够通过管理自己的用户数据库以及安全凭据来达到本身的安全。然而，在一个标准的安全框架下工作将会给最终用户带来更多的好处。没有一个统一的安全性框架时，用户需要为他们所使用的每一个应用记住和管理相应的登录凭据。开发者为每一个组件靠虑到安全性问题。
DCOM通过加入Windows NT提供的非常灵活的安全性标准将安全性用户化的要求简化为对某些特定组件和应用的需求。
使用DCOM安全性标准的应用达到上面例子所要求的有所选择安全性呢？当一个方法调用来到时，组件要求DCOM提供客户的身份。然后根据其身份，被调用线程就仅仅执行允许该客户执行的安全对象中的某些操作。接着组件就试着访问诸如登录字之类的安全对象，这些对象中有一个访问控制列表ACL，如果访问失败，说明客户不在ACL中，组件就拒绝方法调用。通过根据所调用的方法的不同而选择的不同的登录字，组件就能够用一种非常简单，但却灵活而有效的方式提供有选择的安全性。
图14 使用登录字的安全接口
组件也能够很轻易地得到客户的用户名并且利用它在自己的数据库中查找有关的许可和策略。这一策略使用了Windows NT的安全性框架（密码/公钥，传输线上加过密的密码等等）所提供的鉴定机制。应用系统无需为储存密码和其它有关的敏感信息担心。新版本的Windows NT将提供一个扩展的目录服务，它允许应用系统将用户信息存储到Windows NT的用户数据库中。 DCOM的做法更为灵活。组件能够要求不同级别的加密以及不同级别的鉴定，同时可以在自己进行身份认证时阻止组件使用自己的凭据。
Internet上的安全性设计在Internet上公作的应用系统时需要面对两个主要问题。
使是在最大的公司，在Internet上用户的数量都会比原来提高好几个数量级。 最终用户希望对他们所使用的所有应用使用相同的公钥或密码，即使这些应用是由不同的公司所提供的。提供服务的公司不能在应用系统或安全性框架中储存用户的私人密码。 DCOM的灵活的安全性结构怎样帮助应用来解决这些问题呢？对于这一问题，DCOM使用了Windows NT的安全框架（参看安全性部分）。Windows NT的安全性体系结构提供了多个安全性模块，其中包括： Windows NT NTLM鉴别协议，它在Windows NT 4.0以及以前版本的Windows NT中使用。 Kerveros Version 5鉴别协议，它在处理Windows NT中以及Windows NT间的访问时代替NTLM成为最主要的安全性协议。 分布式密码鉴定（DPA），诸如MSN和CompuServe这些最大的Internet成员组织中的某些公司所使用的共享的密码鉴别协议。 安全性通道服务，它被用来完成Windows NT 4.0中的SSL/PCT协议。下一版本的Windows NT将加强对支持SSL 3.0客户鉴定系统的公钥协议的支持。 一个DCE提出的安全性模块，它可以作为第三方工具加在Windows NT中。
所有这些模块都是在标准Internet协议上工作的，都各有其优缺点。NTLM安全性模块以及在Windows NT 5.0中替带它的基于Kerberos的模块都是私人密钥基础协议。它们在集中式管理环境以及使用相互或者单方面信任关系的基于Windows NT服务器的局域网中是非常有效而安全的。对大多数UNIX系统来说，都可以使用NTLM来进行商业实现。（例如AT&T的“Unix系统的高级服务器（Advanced Server for Unix Systems）”）。
使用Windows NT 4.0的目录服务，可以很好地扩展到大约100000个用户。使用Windows NT 5.0的扩展目录服务，一个Windows NT域控制器可以扩展到大约一亿个用户。通过将多个域控制器结合到Windows NT 5.0的目录树中，在一个域中所能支持的用户实际上是无限的。 Windows NT 5.0的基于Kerberos的安全性模块引入了例如在客户进行身份认证时对组件行为的控制等更先进的安全性概念。它在执行鉴别时比NTLM安全性提供模块所占用的资源更少。 Windows NT 5.0还提供了基于安全性模块的一个公共密钥。这一模块可以在基于Windows NT的应用以及基于DCOM的应用中将对于安全性凭据的管理分布化。使用公共密钥进行身份鉴别不如使用私人密钥有效，但是它允许在无需储存客户的私人凭据的情况下进行身份鉴别。 因为有如此多的互不相同的基本的安全性提供模块（私人密钥，公共密钥）可以被使用，所以基于DCOM的分布式应用系统可以无需对其进行任何改动就能完成甚至更为先进，对安全性敏感的应用。Windows NT的安全性框架使得无需牺牲灵活性和执行性能就能很容易地扩展应用并保证应用的安全性。
（下一篇）
