毕业论文Java web 服务 web 服务安全性状态.doc

《毕业论文Java web 服务 web 服务安全性状态.doc》由会员分享，可在线阅读，更多相关《毕业论文Java web 服务 web 服务安全性状态.doc（16页珍藏版）》请在三一办公上搜索。

1、 毕业设计（论文）英文翻译年级专业: 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 stacks Ive covered in this series Apache Axis2,

2、 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.About this seriesWeb services are a crucia

3、l 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 stay informed of the latest developments in

4、 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 configurations, including different types of

5、 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 all. Even testing each possible option va

6、lue 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 usability, based on my research for the l

7、ast 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 conformance to the standard is often a matte

8、r 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 its own testing, along with an even more

9、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 set of standards means youll often encount

10、er 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.Some efforts to improve the quality of web

11、 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 limited because of the small number of confi

12、gurations 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 specified in enough detail, so implementers had

13、 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. This situation creates major problems for

14、 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 configurations by defining best practices ap

15、proaches. 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 generation of web services stacks.Security

16、 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

17、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 digital signatures, BSP 1.1 requires you to fol

18、low 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 you need to do to meet this requirement i

19、snotspecify 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 to those using TripleDes, Aes128, or Aes256

20、 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 contributed to interoperability across web service

21、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 would be very useful to help establish best

22、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 improving the quality of web service securi

23、ty 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 scenarios between their code and the Micros

24、oft 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 configurations tested. The focus on interoperability

25、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 and limitationsIn this column series, Ive te

26、sted 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) demonstrated even more issues. In the case of o

27、ne 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 with respect to the testing I did for the

28、se 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-SecureConversation support, its only compatibl

29、e 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 more requests are made. I consider this a har

30、d 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 issue appears to be rooted in incompatibilitie

31、s 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 disconnect between the core web services eng

32、ine (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. Unfortunately, this has resulted in the security

33、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, so theres no easy way to make it work wit

34、h 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 been corrected as of the latest Axis2 and

35、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, everything is fine, but if this assertionisntused,

36、 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-SecureConversation. The problem in this case

37、 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 significant a problem as the signing issue, i

38、n 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 corrected as of the latest Metro release.CX

39、F 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 use of one-way encryption or signing report

40、ed 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 weaknesses. In trying to give a balanced assess

41、ment, 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 is the security implementation? Performance

42、: 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 overall it seems fairly solid. Score:Axis2

43、 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 with Axis2. Score:Metro 7.CXF has only re

44、latively 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 these articles. Checking the bug-tracking sy

45、stems 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 particular stack. SeeResourcesfor information on t

46、he 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 submission version from 2004, rather than the

47、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-performance rankings. In every form of message-l

48、evel 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 to modify the generated services.xml file to include r