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

毕业设计（论文）英文翻译年级专业: 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 stacks 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.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 stay 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 configurations, 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 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 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 conformance 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 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 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.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 limited 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 specified 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. 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 configurations 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 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 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 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 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 to 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 contributed 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 would 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 improving 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 scenarios 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 configurations 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 and 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) demonstrated 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 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-secureconversation 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 more 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 issue 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 disconnect 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. unfortunately, 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, 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 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, everything 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-secureconversation. 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 significant 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 corrected 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 use 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 weaknesses. 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 is 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 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 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 these 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 particular 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 submission 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-performance 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 to modify the generated services.xml file to include run-time parameters and to activate the security handling. axis2 also tends to silently ignore anything it doesnt understand in the policy configuration. score:axis2 5.metro is probably a little easier than axis2 to work with, but it always requires you to add your run-time parameters into the service wsdl (or at least reference a separate document defining the parameters, on the client side). i believe this is inappropriate, because the wsdl is supposed to represent the published service contract. metro also provides little documentation on configuring and using security features outside of the netbeans/glassfish bundle. finally, in my experience, the error messages you get when theres a configuration problem tend to be obscure, making it difficult to track down the cause. score:metro 6.cxf has the cleanest approach to configuration, normally using separate files for the run-time security parameters on both client and server. you also have the option of configuring everything directly using spring, or in your code. beyond the basic configuration issues, cxf also supports external policy references in wsdl, an important feature for organizations that want to standardize security policies across the enterprise. finally, cxf seems to have the best handling for unsupported policy components, generating warning messages to let you know that the policy is not fully supported. score:cxf 8.table 1 summarizes my rankings:table 1. web service stack rankingsapache axis2sun/oracle metroapache cxfcorrectness678completeness677performance487usability568totals212830these rankings are not intended to be definitive, so if you are using them in making a decision about your own use of a stack, be sure to review my justifications and make your own judgment. also, the rankings apply only to the base open source projects; commercial stacks based on the open source versions may use their own security code and other extensions (as is the case with ibms websphere web services support, which is based on the axis2 runtime but uses entirely different security code). youll need to look at the differences between the commercial code and the open source base to see which parts of the rankings may apply.wrapping upall three of the open source web services stacks looked at in this series to date provide good support for security features. each stack has some strengths and weaknesses in the security area, and in this article, youve seen a summary of how they compare based on my experiences in working with the three over the course of the last dozen or so articles.the next article in the series takes a different tack, looking into the structure of wsdl service definitions and developing a tool to verify wsdls and convert them into the recommended best-practices form.from ibm document libraryjava web 服务: web 服务安全性状态所有主要 web 服务栈都为 ws