分类：
2008-09-10 10:07:35
性是我们大多数客户优先考虑的问题。随着越来越多的客户采用Web服务，他们发现，他们需要了解如何保护Web服务，以及使用何种身份验证机制。为了保持Web服务的开放性并支持多种客户端类型，就必须了解如何处理Web服务的性问题。
本文深入幕后探讨了WebLogic Web服务的安全性问题。我将阐明如何保护WebLogic Web服务，身份验证如何工作，以及如何使用各种编程语言开发客户端来为WebLogic Web服务提供身份验证。
以WebLogic Server作为宿主的Web服务是使用标准的J2EE组件（比如EJB和JMS）来实现的，并且作为标准的J2EE企业应用程序来打包。WebLogic Web服务使用简单对象访问（Simple Object Access Protocol ，SOAP）1.1作为消息格式，并使用HTTP 1.1作为连接。
Web服务运行时组件是一组创建Web服务所需的servlet和相关的基础架构。运行时的元素之一是一组用于处理来自客户端SOA请求的servlet。这些servlet包含在WebLogic Server发布中。运行时的另一个元素是Ant任务，它负责生成和组装WebLogic Web服务的所有组件。
WebLogic Web服务作为标准的J2EE企业应用程序来打包，它由以下特殊组件组成：
在一个RPC风格的Web服务中，无状态会话EJB可以完成Web服务的所有实际工作，或者它们可以把工作分配给其他EJB。Web服务的实现者决定哪些EJB完成实际工作。在消息风格的Web服务中，J2EE对象（通常是消息驱动bean）从JMS目的地获取消息，并且处理它们。WebLogic Web服务作为企业存档（.ear）文件打包，其中包含Web应用程序的Web存档（.war）文件和EJB存档（.jar）文件。
因为WebLogic Web服务作为标准的J2EE企业应用程序打包，所以通过保护组成Web服务的以下标准J2EE组件中的一些或全部，来保护对Web服务的访问：
可以通过保护负责处理客户端和服务之间SOAP消息的SOAP servlet，来保护消息风格的Web服务。
不论是手动还是使用wsgen Ant任务来组装Web服务时，您都可以在Web应用程序的web.xml文件中引用SOAP servlet。这些servelet负责处理在WebLogic Server和客户端应用程序之间传递的SOA消息。它们始终部署在WebLogic Server上，并为所有部署的WebLogic Web服务所共享。
Web服务引用哪个特定SOAP servlet取决于它的类型（RPC风格还是消息风格）。下面列出了对每个SOAP servlet的描述：
清单1
... sender weblogic.soap.server.servlet.DestinationSendAdapter topic-resource-ref senderDestination connection-factory-resource-ref senderFactory
为了限制对DestinationSendAdapter SOAP servlet的访问，您首先定义一个角色，并把它映射到安全域中的一个或多个主体，然后通过把web-resources-collection元素中的如下url-pattern元素添加到Web应用程序的web.xml部署描述器，指定把该安全约束应用到该SOAP servlet。
您可以限制对RPC风格的Web服务的访问，具体方法是限制对实现Web服务或SOAP servlet的无状态会话EJB的访问。清单2和3显示了如何设置web.xml和weblogic.xml文件以保护SOAP servlet。确保客户端仍然能够访问WSDL文件。为了确保这一点，应避免使用通配符映射；而是显式地保护SOAP servlet适配器路径。这两个清单提供了一个如何保护帐户管理程序代理Web服务的例子。正如您所看到的那样，角色是在web.xml中定义的，并与域中的组相关联。
清单2Weather /weatherturi/* Admin BASIC Admin
清单3Admin system
为了理解如何处理Web服务客户端的安全性问题，必须要理解SOAP和HTTP身份验证的工作方式。
Web服务使用SOAP，它是以一些底层传输机制为基础而实现的高级消息传送协议。Web服务安全性仍然是一个新兴领域，围绕SOAP规范出现了一些扩展，以支持安全功能。当前，SOAP使用的是针对身份验证的底层传输协议基础架构。所以，WebLogic Server SOAP间接地使用了HTTP 1.1身份验证。
使用HTTP的用户身份验证方法十分简单。因为HTTP是一个无状态协议--也就是说，一旦请求完成之后，不会记住关于该请求的任何信息--浏览器需要为每个请求重新发送用户名和密码（参见图1）。
图1
第一次访问需验证的资源时，将返回401状态（“Unauthorized”），并包括一个WWW身份验证的响应头，用于指明所使用的域名和身份验证模式。然后，浏览器应该要求用户输入用户名和密码。接着，它再次请求同样的资源，这次包括了一个含有模式名（“Basic”）的身份验证头，以及输入的用户名和密码。服务器检查此用户名和密码，如果它们是有效的，就会返回相应的页面。如果密码对于该用户无效，或者用户没有访问权限，服务器还会像以前一样返回401状态。然后，浏览器可以要求用户尝试重新输入用户名和密码。
假定用户名和密码有效，接下来用户可能会请求一个受保护的资源。在这种情况下，服务器将使用401状态作为响应，而浏览器能够使用用户和密码详细信息再次发送请求。这样做会很慢，然而对于随后的请求，浏览器就会改为发送身份验证头。要了解HTTP身份验证方面的更多信息，请参考W3C HTTP Working Group RFC 2617 ()。
虽然前面的部分着重于浏览器客户端，但是协议对于任何类型的客户端都是相同的。任何需要访问受保护的Web服务的客户端都要理解这个HTTP身份验证协议，并实现它以求通过身份验证。这个部分说明了如何传送来自各种类型客户端的身份验证信息。
Microsoft为传输层提供HTTPConnector接口。它使用两个属性来传递证书--AuthUser 和AuthPassword。清单4显示了一个使用Visual Basic和MS SOAP Toolkit 2.0调用一个受保护的WebLogic Web服务的例子。
