用Win2000 Active Directory保护应用程序之四

基本认证之外的话题

　　如果认证过程中某一个步骤失败，需要在代码中作相应的处理使用户知道这些。你的第一个主意可能是“弹出一个拒绝访问的对话框，在点确认的同时退出应用程序”，但是很遗憾此路不通。这对程序来讲可能解决了问题，但根本不会对用户有任何帮助。

用提示用户输入有效的证书，随后用这个证书重新尝试验证的办法取代前面的解决办法，从而为用户和应用程序验证失败提供一条合理的出路。请见下图：

　　你可以点击此处下载全部源代码来执行对话框。注意：你并没有真正把用户登录到域或者本地计算机，你仅仅验证了一下想访问应用程序的用户提供的用户名和密码，继而证明用户是否属于AD中的某些组。
　
　　除非你正在使用DCOM或其它集成安全的技术，否则这些认证是不成问题的。如果需要集成的NT安全，就需要额外的代码来调用LogonUser，同时要面对所有调用这个API所带来的问题，例如NT的安全在Win9x上不起作用。

　　当你忙于实现好于往常的安全特性时，你可能也想加入基于特征的认证。很多应用程序都有某类功能（例如删除数据库或重要的商业逻辑）只允许授权用户使用。代替依靠某类硬代码操作的密码来保护这些功能，你可以让管理员基于程序功能创建特定的组来界定用户对功能的访问权限。你可以通过使用证书缓存技术实现这些功能，从而避免使应用程序慢许多。证书缓存包括在有限的时间段记忆成功登录的用户，以避免反复访问目录服务器做验证。

　　如果应用程序的逻辑是跨越多层的结构，作为极流行的商务应用程序案例，不能仅将安全控制停留于客户端的有目录功能的代码上面。实际上，通过多种办法让系统的商务逻辑和数据库组件有坚固的安全功能比安全化客户端应用程序更加重要。因为，毕竟对于哪些怀有恶意的用户来讲，可以完全绕过你的客户端程序，直接基于ActiveX来调用中间件或者直接对数据库执行SQL查询，这时客户端的安全限制就显得太微不足道了。幸运的是，阻止这些企图也很简单：COM组件几乎总是运行在当前登录用户的安全上下文中，也就是说项目中的ActiveX部分可以使用这一技术来验证用户证书。本文的例程代码包括了一个简单的端到端的此项技术演示示例。

　　DCOM/COM+ 的安全变得更加复杂，因为这里有几个很可能有问题的安全情境。尤其象是有多个域或者用户匿名访问时更加棘手。但即使在DCOM或COM+中，最普通的情况同样是远程实例化的对象运行在登录到机器并且发出请求的域用户的安全上下文中，这也就意味着你的验证代码可以很好地运行。

　　如何对数据库实施安全措施，最终完全依赖于你使用的是哪一种数据库引擎。MS SQL Server的最近版本允许你在其中应用全部的NT安全（当使用Windows 2000的域控制器时，它自动包含AD的支持）并且提供数据表级的组和用户的访问许可控制。最好的办法是允许NT验证防止SQL server独立验证（这也防止了缺省的SQL server系统管理员密码的麻烦）并且用组（你用来决定是否有权访问应用程序的组）来限制对表的访问。

　　作为一个规则，任何没有应用程序访问权限的非管理组也一定没有数据库访问权限。如果一组用户对应用程序的某些功能受限，例如正常的用户只能读取系统表，但无权修改和删除，那么在数据表的许可中也应该反映出来。

　　不论是使用端到端跨越所有应用程序分层的授权验证还是为程序简单地添加一个登录窗口，你都会发现AD提供了更多直接的办法来实现以前很难完成的安全特性。一句话，应用程序将受益于Windows 2000 Active Directory的安全特性。