1.2 可靠的安全架构

一个Web应用系统包含了诸多功能，如果只单一的加固每个功能模块的安全性，只能使得系统的安全性支离破碎。为了实现应用系统整体的安全性，开发人员需要明确编程语言的安全技术各个部分是如何相互协作的。

本书讨论的Web应用系统的安全模型包括：ASP.NET、企业服务和Web服务，下面就逐一介绍每个组成部分的安全性。

1．ASP.NET的安全性

ASP.NET用于实现用户界面服务。通过将已验证的凭据或它们的表示形式与某些内容进行比较，ASP.NET可以控制对站点信息的访问。这些内容可以是NTFS文件系统权限，也可以是列出了已授权用户、已授权角色（组）或已授权的XML文件。

ASP.NET身份验证模式包括匿名、Windows、Passport和窗体身份验证。

• 匿名身份验证。如果不需要对客户端进行身份验证（或者实现自定义的身份验证方案），则可以配置IIS进行匿名身份验证。在这种情况下，Web服务器创建Windows访问令牌来表示使用同一个匿名（或来宾）账户的所有匿名用户。默认匿名账户是IUSR_MACHINENAME，其中MACHINENAME是在安装时为计算机指定的NetBIOS名称。
• Windows身份验证。在这种身份验证模式下，ASP.NET依靠IIS对用户进行身份验证并创建Windows访问令牌来表示经过身份验证的标识，IIS提供的身份验证机制见下面详细说明。
• Passport身份验证。在这种身份验证模式下，ASP.NET使用Microsoft Passport的集中式身份验证服务。ASP.NET对Microsoft Passport软件开发工具包SDK（必须安装在Web服务器上）提供的功能进行包装。
• 窗体身份验证。此方法使用客户端重定向将没有经过身份验证的用户转发到指定的HTML窗体，用户可以在该窗体中输入证书（通常是用户名和密码）。然后，系统对这些证书进行验证，生成身份验证票并将其返回客户端。身份验证票上有用户标识，还可以选择在身份验证票上列出用户在会话期间所属的角色。

有时，窗体身份验证只用于Web站点的个性化处理。在这种情况下，几乎不用编写任何自定义代码，因为ASP.NET用简单的配置自动处理这一过程的大部分工作。在个性化处理方案中，Cookie只需要保留用户名即可。窗体身份验证以明文形式向Web服务器发送用户名和密码。因此，应该将窗体身份验证与SSL保护的信道结合使用。为了对后续请求中传输的身份验证Cookie不间断地提供保护，应该考虑在应用程序内的所有页上使用SSL。

IIS提供的身份验证机制分为如下几种：

• 基本身份验证。基本身份验证要求用户以用户名和密码的形式提供证书以证明其标识。用户证书以不加密的Base64编码格式从浏览器传送到Web服务器。由于Web服务器得到的用户证书是不加密的格式，因此Web服务器可以使用用户证书发出远程调用。
• 摘要式身份验证。这种验证方式从浏览器向Web服务器传送用户证书时采用哈希格式，因此更为安全。不过它要求使用Internet Explorer 5.0或更高版本的客户端以及特定的服务器配置。
• 集成Windows身份验证。集成的Windows身份验证使用与用户Internet Explorer Web浏览器的加密交换来确认用户标识。只有Internet Explorer支持这种验证。所以，这种验证一般只能在Intranet方案中使用，因为能够控制Intranet中所用的客户端软件。如果禁用匿名访问，或拒绝通过Windows文件系统权限进行匿名访问，那么这种验证只能由Web服务器使用。
• 证书身份验证。证书身份验证使用客户端证书明确地识别用户，客户端证书由用户的浏览器（或客户端应用程序）传递到Web服务器（如果是Web服务，则由Web服务客户端通过HttpWebRequest对象的ClientCertificates属性传递），Web服务器从证书中提取用户标识。该方法依赖于用户计算机上安装的客户端证书，一般在Intranet或Extranet方案中使用，因为使用者熟悉并能控制Intranet和Extranet中的用户群。IIS在收到客户端证书后，可以将证书映射到Windows账户。
• 匿名身份验证。如果不需要对客户端进行身份验证（或者实现自定义的身份验证方案），则可以配置IIS进行匿名身份验证。在这种情况下，Web服务器创建Windows访问令牌来表示使用同一个匿名账户的所有匿名用户。默认匿名账户是IUSR_MACHINENAME，其中MACHINENAME是在安装时为计算机指定的NetBIOS名称。

2．企业服务的安全性

企业服务（Enterprise Services）为应用程序提供基础结构级的服务，主要包括分布式事务和资源管理服务。

如图1-2所示的企业服务应用程序使用RPC方式对调用方进行身份验证。也就是采取特定的步骤禁用身份验证；否则就应该使用Kerberos或NTLM对调用程序进行身份验证。

授权是通过企业服务（COM+）角色提供的，这些角色可以包含操作系统组或用户账户。角色成员身份在COM+目录内定义并利用“组件服务”工具进行管理。如果客户端（如ASP.NET的Web应用程序）在服务组件上调用某个方法，企业服务侦听层在身份验证进程结束后访问COM+目录以确定该客户端的角色成员身份，然后检查该角色是否允许授权访问当前的应用程序、组件、接口和方法。

3．Web服务的安全性

Web服务通过使用SOAP消息在防火墙之间或跨平台系统之间移动数据来实现数据的交换和应用程序逻辑方法的远程调用。

Web服务的安全性主要包括平台/传输级（P2P）安全性、应用程序级（自定义）安全性、Remoting安全性、ADO.NET安全性、Internet协议安全性和安全套接字层。

1）平台/传输级（P2P）安全性

两个终结点之间的传输通道（Web服务客户端和Web服务之间）可以用于提供点对点的安全性，如图1-3所示。

2）应用程序级安全性

应用程序使用自定义的SOAP标头传递用户凭据，以便根据每个Web服务请求对用户进行身份验证。常用的方法是在SOAP标头中传递身份验证票。

应用程序可以灵活生成其包含角色的IPrincipal对象。该对象可以是自定义类或.NET框架提供的GenericPrincipal类。应用程序可以有选择地加密需要保密的内容，但是这需要使用安全密钥存储。

另一种方法是使用SSL提供机密性和完整性，并将它与自定义的SOAP标头结合起来执行身份验证。

3）Remoting安全性

Remoting技术可以跨越进程和机器边界访问分布式对象。使用Remoting技术和ASP.NET应用程序客户端时，就会在Web应用程序和远程对象主机上进行身份验证。

当Remoting技术在ASP.NET中应用时，可以使用HTTP通道在客户端代理和服务器之间传递方法，包括IIS身份验证和ASP.NET身份验证。

当Remoting技术在Windows服务中应用时，可以使用TCP通道在客户端和服务器之间传递方法调用，它使用基于套接字的原始通信方法。

4）ADO.NET安全性

ADO.NET是专门为分布式Web应用程序设计的，它的安全性主要包括SQL Server外盾、Windows验证和ASP.NET验证。

SQL Server外盾守卫需要保存数据库连接字符串，登录数据库并获取关联的数据库角色，其过程如图1-4所示。

使用Windows身份验证从ASP.NET应用程序连接到SQL Server时，可以采用ASP.NET进程标识，也可以采用固定标识。通常的做法是在Web服务器上将密码更改为某个已知值来配置本地ASP.NET进程标识，然后在数据库服务器上通过创建具有相同用户名和密码的本地用户创建镜像账户。

5）Internet协议安全性

Internet协议安全性提供了一种传输层安全通信解决方案，可以保护如应用程序服务器和数据库服务器之间的数据传递，通过对两台计算机之间发送的所有数据进行加密来提供消息的保密性，同时在两台计算机之间提供相互的身份验证。

6）安全套接字层

安全套接字层（Secure Sockets Layer）提供点对点的安全通信信道。通过该信道传输的数据都是经过加密的。SSL技术最常用于保护浏览器和Web服务器之间的信道，也可以用于保护往返于运行数据库服务器和Web服务器之间的消息。

使用SSL时，客户端使用HTTP协议并指定一个URL，而服务器在TCP端口900上侦听。由于SSL使用复杂的加密功能来对数据进行加密和解密，因此对应用程序的性能会产生影响，所以应该优化使用SSL的页面。 VMtCtlVjXchOP6Ys3FYN2+qTvC59sLdvkQudJQPl5L1IF7+vNvpb2nc24NdT62S1