javax.xml.rpc.soap.SOAPFaultException: Unable to add security token for identity

　　客户端试图调用服务，但又不提供任何授权凭证。客户端代码需要加以修改，以便使用刚才创建的用户名/密码suzie/munchkin来调用服务。现在开始向HelloWorldClient.java的main方法添加下面突出显示的代码：

　　运行代码，会返回正常的问候消息。这样，我们就知道了客户端调用服务前被强制添加凭证。查看监视器，检查请求，应该看到一个新的部分：

　　这些的确是我们提供的凭证。注意，这些凭证以纯文本发送。WS-Security规范没有涉及用户凭证加密;而是推荐采用传输层安全措施(即，保护整个TCP/IP套接字)。

　　身份验证已经成功地加入Web Services了!

　　展望未来：WebLogic Server 10的安全性配置

　　WebLogic Server 10最近已发布。对于现有的受保护的Web services，这意味着什么呢?幸运的是，变化不是很多。第十版中服务的部署和运行没有变化。然而，客户端代码需要使用第十版的客户API重新生成。此外，WebLogic Server 10加入了WS-SecurityPolicy 1.2支持，现在它支持WS-Security 1.1。(WebLogic Server 9.2支持WS-Security 1.0。)

　　WS-SecurityPolicy 1.2的重要性在于可以创建与BEA专有安全策略文件相对的“标准”安全策略文件。WS-SecurityPolicy规范发布之前发布的WebLogic Server 9.2使用的是依据采用专有BEA安全策略模式的旧版WS-Policy规范写成的安全策略文件。

　　应该采用哪一种策略文件?BEA建议采用WS-SecurityPolicy标准策略文件代替其专有策略文件。实际上，这两种策略文件第十版都支持，但这二者是不兼容的，所以一个给定的Web Services只能采用二者之一。

　　可是在您急着将WebLogic Server 9.2策略文件迁移到新标准之前，谨记WS-SecurityPolicy尚有局限之处，因为在BEA实现它的时候，它还只是(依然是)一个草案。具体来说，如果您需要元素级的数字签名和/或加密，或者要求SAML 1.1，那么您仍然必须采用专有的BEA WebLogic 9.2型策略。

　　根据WS-Security，即使WebLogic Server 10支持WS-Security 1.1，BEA仍然推荐为了互操作性使用WS-Security 1.0策略。只是当您要求更强的安全性时，才应该采用WS-Security 1.1策略。而且只有使用新的WS-SecurityPolicy 1.2策略文件，WS-Security 1.1才被支持。

　　结束语

　　在本文中，我们讨论了Web services安全性的三个方面：消息的完整性、机密性和身份验证。我们已经看到编写含有这三个方面的“安全”Web Services非常简单;所要做的只是用适当的注释来注释Web Services代码。我们了解了使用什么注释来实现每个方面，弄清了必须如何修改客户端代码调用受保护的服务，看到了SOAP消息自身如何改变以反映新加入的安全性。在教程中，我们建立了一个Web Services，并逐步加入所有三个方面。

　　由于SOAP消息的“纯文本”的性质，当我们部署Web services作为企业生产环境的一部分的时候，强大的安全性是非常重要的。WS-Security与WebLogic Server的结合为这个问题提供了一个极好的解决方案，使开发人员得以轻松地部署和维护企业服务。