《毕业论文---Java web 服务 web 服务安全性状态.doc》由会员分享，可在线阅读，更多相关《毕业论文---Java web 服务 web 服务安全性状态.doc（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 W
17、S-I, most of these requirements deal with web services stack implementations rather than end-user security configurations. BSP 1.1 does not deal with WS-Security configuration in WS-SecurityPolicy at all, but a few of its requirements can be translated into WS-SecurityPolicy terms.When you use digit
18、al signatures, BSP 1.1 requires you to follow the W3C Exclusive Canonicalization Recommendation, an XML canonicalization algorithm that ignores comments and unnecessary context information (seeResources). This algorithm is the default assumed by WS-SecurityPolicy in the absence of any choice, so all
19、 you need to do to meet this requirement isnotspecify a different canonicalization algorithm (such as).BSP 1.1 also adds some other requirements for both signatures and encryption that constrain the algorithm-suite values defined in WS-SecurityProfile, but these basically just restrict the choices t
20、o those using TripleDes, Aes128, or Aes256 encryption, and SHA1 digesting (excluding only the Aes192 encryption and SHA256 digest options offered by WS-SecurityPolicy). Other BSP recommendations restrict how various security tokens are to be referenced and used.The WS-I BSP has undoubtedly contribut
21、ed to interoperability across web service security implementations, but aside from these minor points, it hasnt done anything toward reducing the complexity of security-configuration choices. An updated version of the BSP that was more-specifically oriented toward WS-SecurityPolicy configurations wo
22、uld be very useful to help establish best practices for security architects using modern policy-based configurations, but unfortunately the WS-I has not shown interest in such an update.Interoperability testsVendor-driven interoperability testing across stacks has been a more significant factor in i
23、mproving the quality of web service security implementations. Microsoft has been a driving force in this area, hosting a series of interoperability plug-fests at its campus where developers of other web services stacks (both commercial and open source) are invited to participate in testing various s
24、cenarios between their code and the Microsoft implementation (seeResources). Security has been a major focus of the plug-fests.This interoperability testing has helped establish a basic level of compatibility among stacks, but the benefits have been limited because of the small number of configurati
25、ons tested. The focus on interoperability with the Microsoft implementation (rather than a test suite based on the actual standards) has also been a limitation, though in practical terms this is much easier to handle than full cross-compatibility tests among a dozen or more stacks.Security issues an
26、d limitationsIn this column series, Ive tested a variety of security configurations on three web services stacks, finding several issues with each stack. Limited interoperability testing (using one stack for the client and another for the server, only tried for the WS-SecureConversation tests) demon
27、strated even more issues. In the case of one stack, Apache Axis2, I also found significant performance problems. All these issues have been reported to the developers for each stack, and some have been fixed in the latest releases. In this section, Ill summarize the current state of the three stacks
28、 with respect to the testing I did for these articles.Axis2 issuesThe problems I found with Axis2 include WS-SecureConversation policy handling, wherein the bootstrap policy definition appears to be completely ignored in operation. Because this means Axis2 uses a canned configuration for its WS-Secu
29、reConversation support, its only compatible with other stacks using that same configuration.In terms of the security runtime, Axis2 has a major issue with client-side handling of symmetric bindings (as discussed in WS-Security without client certificates). The client runs progressively slower as mor
30、e requests are made. I consider this a hard bug, rather than a performance issue, because of the progressive nature of the problem.Axis2 security handling is also plagued by consistently slow operation any time security is used (see CXF performance comparison for some results). This performance issu
31、e appears to be rooted in incompatibilities between the AXIOM object model used by Axis2 and the standard DOM used by the security code, so the problems are likely to continue until and unless AXIOM is enhanced to provide full DOM compatibility.Finally, in my opinion, Axis2 tends to suffer from a di
32、sconnect between the core web services engine (the actual Axis2 code) and the security code (the Rampart and Rahas security modules). Early on we (the Axis2 committers) decided to separate the security code from the core code, allowing these components to be separately enhanced and released. Unfortu
33、nately, this has resulted in the security code being treated as an optional component, and Axis2 releases have been made that do not work with the then-current Rampart release. The recent Axis2 1.5.2 release is an example: the binary distribution is missing a JAR file required for security handling,
34、 so theres no easy way to make it work with Rampart. This was corrected in the current Axis2 1.5.3 release, but the very fact that an official release would ship without working security support demonstrates the disconnect.None of the significant Axis2 problems I found in writing these articles has
35、been corrected as of the latest Axis2 and Rampart releases.Metro issuesTests for the articles in this series also revealed some significant problems with Metro. The biggest problem is Metros handling of signing message bodies. If the policy includes a OnlySignEntireHeadersAndBody assertion, everythi
36、ng is fine, but if this assertionisntused, Metro incorrectly signs the content of the body, rather than the body element itself. Stacks that handle the signing correctly will reject messages signed in this way by Metro.Metro also broke with the WS-SecureConversation policy used in WS-Trust and WS-Se
37、cureConversation. The problem in this case was that the policy used different algorithm suites for the bootstrap message exchange with the Security Token Service (STS) and the actual conversation with the service. Metro ignored this and just used a single algorithm suite for both. This is not as sig
38、nificant a problem as the signing issue, in that theres little reason to use two different algorithm suites in practice, but its still an error.Finally, Metro also had problems relating to the use of one-way encryption or signing reported in Understanding WS-Policy. None of these problems has been c
39、orrected as of the latest Metro release.CXF issuesJust as with the other stacks, I found some CXF problems in testing for these articles. In almost every case, the problems were corrected in a new CXF release before the article was published. The only exception was for the problems relating to the u
40、se of one-way encryption or signing reported in Understanding WS-Policy, which have now been corrected in the CXF 2.3.1 release.Comparing the stacksAny attempt to rank web services stacks on their security support will necessarily be highly subjective, because each stack has both strengths and weakn
41、esses. In trying to give a balanced assessment, Ive broken the ranking down into four factors and assigned a numeric rating in the classic 1-to-10 (worst-to-best) range for each stack: Correctness: How many implementation errors are known, and how serious are the errors? Completeness: How complete i
42、s the security implementation? Performance: How much overhead does the security handling add? Usability: How easy is it to configure the security code?CorrectnessAxis2 has some significant problems, and the disconnect between the core code and the Rampart security module is an issue of concern, but
43、overall it seems fairly solid. Score:Axis2 6.Metro has some major issues, in particular the incorrect handling of signatures when used without. Like Axis2, though, it generally seems fairly solid, and the integration of the security code into the main release makes complete failures less likely than
44、 with Axis2. Score:Metro 7.CXF has only relatively minor known issues, and the fast responses to problems and quick release cycle mean problems generally are corrected soon after theyre found. Score:CXF 8.To be fair on this point, Ive only considered problems experienced directly in the course of th
45、ese articles. Checking the bug-tracking systems for the stacks will show other, potentially more significant, problems. You need to use care when looking at these some of the problems reported may be caused by user errors but its a worthwhile exercise if youre considering standardizing on a particul
46、ar stack. SeeResourcesfor information on the bug-tracking systems for the three stacks.CompletenessAll three stacks provide support for all the major security standards. However, Axis2 support is limited in at least two respects. For WS-Policy, Axis2 code generation only works with the outdated subm
47、ission version from 2004, rather than the standard W3C version released in 2007. For WS-SecureConversation, Axis2 implements a canned configuration, ignoring any policy configuration you supply.Scores: Axis2 6; Metro 7; CXF 7.PerformanceAxis2 is clearly the loser when it comes to any security-perfor
48、mance rankings. In every form of message-level security handling it creates much more processing overhead than either Metro or CXF. Metro is slightly faster than CXF overall, so for this factor my scores are:Axis2 4; Metro 8; CXF 7.UsabilityAxis2s security configuration is somewhat painful. On the client side, it requires you either to embed run-time parameters into the service WSDL or to configure the parameters directly in your client code. Either way, you must actually activate the security handling in your client code. On the server side, you have t