安全是应用软件的基本设计出发点之一。它是一个系统架构的基本组成部分之一。
　
　　安全系统分为身份识别与权限认证两部分。身份识别即通过技术手段，找出当前的用户是谁；而权限认证则是在系统执行期间，找到当前用户对于一些安全托管对象是否具有指定的操作权限。

　　在设计应用程序时，我们可以选择自己从头做安全系统，比如常见在数据库中设计出一个用户表，角色表，以及权限表，根据它们的关系做出相应的操作。但是，实现一个真正的安全系统是非常复杂的。比如在这样的设计模式下，几个常见的安全缺陷有：系统管理员直接到数据库中去改密码或查密码；而如果是C/S结构的程序，常见的做法是将用户的ID存放于客户端的内存变量之中，这时，一个简单的内存修改程序，就可以将一个低权限的身份，切换为高权限的，比如直接将我的ID修改为公司财务总监的。

　　那么，如何以一个相对较小的代价实现一个足够安全的系统呢？在本篇文章中，试图给出一个答案。

        一、目录服务

　　从文章中的标题中，你也可以猜出，这里是说到目录服务。那么，什么是目录服务？

　　简单地说，目录服务是一个集中的对象数据库。从它的最初设计来讲，它并不是单独为了安全而设计的。不过，在后来的发展中，目录服务慢慢成为了系统的安全中心。在目录服务中存在的对象，基本上都是一些安全控制对象（Securable Object）。常见的包括，用户、用户组、计算机等。现在市场上有很多不同类型的目录服务器产品，在微软平台上的就是有名的Active Directory Server（活动目录服务器）。需要指出的是，不管你是何种类型的目录服务器，它的编程接口都是一致的，这就是LDAP接口（Lightweight Directory Access Protocol），不同的服务器可能对于编程接口有所扩展，但是，LDAP接口是其最基本的部分。比如微软的活动目录，除了支持LDAP之外，还有自己的一套ADSI接口。

　　如果没有操作系统的支持，目录服务的功能是不会有如此大的能力的。现在主流的操作系统都已支持了各种不同类型的目录服务器，这是确保目录服务器成为安全中心的重要前提。下面，我将以微软的Windows操作系统为例，简单说明一下操作系统以及目录服务器是如何给应用程序的安全体系架构提供了良好的支持的。

　　在典型的企业网络部署中，网络的接线，保证了系统的连通。无论这个网络规模的大小，在这个网中，都被规划了一个或多个域（Domain），这里的域，其实就被映射到一个目录服务器的根。域服务器同时也是目录服务器。网络中的所有计算机都被加入到域中，同时，这些机器在域中也有了一个相应的帐户，表示计算机。这时，系统管理员只需要坐在自己的办公桌前，通过查看活动目录管理控制台，就可以知道各个机器的工作情况。甚至可以扫描各台机器的注册表，以观察域中的机器工作是否正常。

　　所有能够登录到被注册到域的机器的用户，同样在目录服务器存有记录。当用户登录到机器时，操作系统会自动寻找到用户的记录，验证用户名、密码，如果验证通过，则用户登录成功，能够进行后续的操作。

　　或许这个过程没有什么神奇之处，但是，问题的关键是，这里解决了两个很关键的安全问题：一个身份识别过程中的安全；二是身份的存储安全。在 Windows中，身份识别过程是加密的，也是安全的。而身份存储则更为重要，在用户登录成功之后，它的安全访问令牌（Access Token）只可以通过编程方式获得，但是，你是不可能通过内存访问的方式去获得的。

　　当然，因为目录服务器的存在，用户也不用担心某一天系统管理员心血来潮去查看他设置的密码，因为这个密码是不可逆加密的。也就是说，系统管理员他只可以重新设置用户的密码，但是，却无法查到密码。这对于安全性而言，也至关重要。

        二、集成目录服务安全

　　在简单了解了应用目录服务器来设计安全体系的基础环境之后，我们就可以开始着手设计自己应用程序的安全体系了。回到最初的问题，这包括两个部分，一个身份识别；二是权限认证。

        2.1 身份识别

　　在身份识别部分，有两种选择，一种是直接利用当前的登录用户。所有的应用程序都有安全上下文（Security Context），在其中，可以找出当前用户的身份。如果是普通的桌面应用程序，则安全上下文中包含的就是当前的登录用户。如果是Windows 系统服务，则安全上下文中包含的就是系统管理设置的此服务的启动帐号。

　　直接利用安全上下文是一种最为简单的方法，但是，它还是有一些缺陷，即要想换用户登录，必须强制用户注销系统，然后，以另外一种身份登录。这在有些情况下是不适合的。比如我见过的一个应用是"用户要向网络系统管理员报告他的帐号被锁定了，即不能够登录。"，这时，如果你还是要求他必须先登录到系统，然后，再提交报告，这个事情就停在那里永远完成不了。

　　所以，身份识别还有第二种方式：应用程序认证。在实现应用程序认证的时候，与前面不同，应用程序本身不需要维护一个数据库来存放用户的名字等内容，用户输入用户名与密码之后，验证通过目录服务器来进行。在Windows XP开始，操作系统开放了用户身份认证接口，你甚至可以通过调用操作系统本身的登录服务，来完成这个过程，以获得更高的安全性。

　　当然，如果你自己来做身份认证时，身份的保存问题同样被提了出来。所以，这方面必须小心设计。一般情况，可以将用户的安全识别号（SID，一个GUID值）存放到本地内存中。后续的权限认证基于此SID来进行，而不是根据一些可读的字符串进行，这样会更为安全一些。

        2.2 权限认证

　　接下来的就是权限认证。如果你要完成的是一个声明为集成目录服务安全认证的程序，那么，你的权限认证应该是基于用户在目录服务器的组，而不是其它另外的资源的。

　　我们经常会有意识无意识在使用数据库来存放用户所属的角色，这样做引入了安全缺口。正确的做法就是使用目录服务器。比如你的应用程序中可能规则只有财务人员才可以通过应用程序填写凭证。这时，你可以在目录服务器设置一个用户组，所有属于该组的人员即为财务人员。而在用户要访问凭证功能时，验证当前的用户是否为该组的成员即可。

　　有时，你也许会发现，你的权限要求比较复杂，觉得目录服务不能够完成你的要求。那么我的建议是：你再考虑一下。因为这个目录服务器模式已经被证明行之有效很长时间了。因为，我们还有最后一个办法，就是扩展目录服务器的功能。虽然这个过程比较复杂，但是，它可以确保你想要的都可以实现。

        2.3 对象级权限设置

　　在本节的最后，我想加入对象级权限设置的内容。

　　所谓对象级权限，就是说对于系统内的每一个对象进行授权。它是相对于功能级权限而言的。比如凭证管理功能。如果我们说哪一类人允许做凭证，哪一类人不可能，这是功能级权限。而如果我们说哪一个人对于某一张凭证具有修改权限，这就是对象级权限。

　　相对而言，实现功能级权限是容易的。因为通常我们都会将功能映射到角色／用户组上。而且这个实现对于负载而言，是比较轻的。应用程序实现起来也不复杂。但是，当我们计划要实现对象级权限的时候，问题就会复杂起来。因为这里首先面临的就是系统权限管理的复杂性以及权限变化跟踪的复杂性。在这篇文章中，就不再展开说明。有兴趣的朋友可以进一步交流。

        三、结束语

　　在TAO的技术体系中，集成目录服务的安全模型是一个重要的组成部分，它实现了功能级权限与对象级权限的混合应用。