《毕业论文Java web 服务 web 服务安全性状态》由会员分享，可在线阅读，更多相关《毕业论文Java web 服务 web 服务安全性状态（17页珍藏版）》请在金锄头文库上搜索。
1、 毕业设计（论文）英文翻译年级专业: 2008级软件工程 姓名: 学号: 312008080611322指导教师: 年级 2008级 专业 软件工程 学号 312008080611322 姓名 周进 Java web services: The state of web service securityAll major web services stacks provide some level of support for WS-Security and related web services security standards. The three open source stack
2、s Ive covered in this series Apache Axis2, Sun/Oracle Metro, and Apache CXF all provide a fairly high level of support for these standards. But their support differs significantly in many ways, including both the security operation and how the stacks are configured with run-time security parameters.
3、About this seriesWeb services are a crucial part of Java technologys role in enterprise computing. In this series of articles, XML and web services consultant Dennis Sosnoski covers the major frameworks and technologies that are important to Java developers using web services. Follow the series to s
4、tay informed of the latest developments in the field and aware of how you can use them to aid your programming projects.One important area of difference relates to the completeness and correctness of the security implementations. WS-Security and WS-SecurityPolicy allow many variations of security co
5、nfigurations, including different types of keys and certificates, algorithm suites, security tokens, and signing/encrypting specifications. WS-Trust and WS-SecureConversation expand the number of options even further. With so many possible configurations, no web services stack can possibly test them
6、 all. Even testing each possible option value in isolation is difficult, and most stacks dont try.In this article, youll first learn more about the issues of security interoperability among web services stacks. Then you see how the Axis2, Metro, and CXF compare on several measures of correctness and
7、 usability, based on my research for the last dozen or so articles of this series.Security interoperabilitySecurity standards provide far too many combinations of options for comprehensive testing. Many of the standards supply little in the way of examples, and nothing in terms of test suites, so co
8、nformance to the standard is often a matter of opinion and conjecture. As a result, stacks that claim to support a particular standard rarely do any extensive verification of their support.Instead of trying to test against the standard, each stack uses a limited number of security configurations for
9、 its own testing, along with an even more limited number of configurations in interoperability tests with other stacks. Other than that, the developers for each stack respond to bug reports from users encountering security configuration or interoperability issues. This limited testing for a complex
10、set of standards means youll often encounter problems if you try anything thats not in the mainstream. Even in the relatively small number of security configurations tested for the security discussions and performance comparisons in the articles of this series, I found several problems of this type.
11、Some efforts to improve the quality of web services security code have been made, including the work of an industry-wide organization and vendor-driven interoperability testing. The latter, in particular, has helped establish a basic level of compatibility among stacks, but the benefits have been li
12、mited because of the small number of configurations tested.WS-I Basic Security ProfileFrom the start, SOAP web service specifications have offered many choices for implementers and users. Partly this was by design. Other cases are due to oversights in the standards: Expected behaviors were not speci
13、fied in enough detail, so implementers had to guess what needed to be done. The problem with too many choices is that implementers lack the resources to test all the possible combinations fully, so the web services stacks support some sets of choices well, others poorly, and still others not at all.
14、 This situation creates major problems for interoperability, because theres no guarantee that different stacks support the same choices.Choice overload was such a problem in the early years of SOAP that an industry-wide group was created for the specific purpose of limiting the number of possible co
15、nfigurations by defining best practices approaches. This group, the Web Services Interoperability Organization (WS-I), produced a number of profiles requiring particular choices to be used or avoided (seeResources). Through these profiles, WS-I has had a major influence in shaping the current third
16、generation of web services stacks.Security is one of the areas WS-I has covered in profiles. The WS-I Basic Security Profile Version 1.1 (referred to as BSP 1.1) is the current main document in the security area. This document includes a wide range of requirements, but in keeping with the focus of WS-I, most of these requirements deal with web services st
