外文翻譯---java web 服務(wù) web 服務(wù)安全性狀態(tài)

1、<p><b>　　畢業(yè)設(shè)計(jì)（論文）</b></p><p><b>　　英文翻譯</b></p><p>　年級專業(yè):2008級軟件工程 </p><p>　姓名:</p><p>　學(xué)號:312008080611322</p><p>　指導(dǎo)教師:<

2、/p><p>　　Java web services: The state of web service security</p><p>　　All major web services stacks provide some level of support for WS-Security and related web services security standards. The t

3、hree open source stacks I've 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 w

4、ays, including both the security operation and how the stacks are configured with run-time security parameters.</p><p>　　About this series</p><p>　　Web services are a crucial part of Java techno

5、logy's 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.

6、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.</p><p>　　One important area of difference relates to the complet

7、eness 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 to

8、kens, 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 test

9、ing e</p><p>　　In this article, you'll 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

10、correctness and usability, based on my research for the last dozen or so articles of this series.</p><p>　　Security interoperability</p><p>　　Security standards provide far too many combinations

11、 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 conjectu

12、re. As a result, stacks that claim to support a particular standard rarely do any extensive verification of their support.</p><p>　　Instead of trying to test against the standard, each stack uses a limited n

13、umber 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 re

14、ports from users encountering security configuration or interoperability issues. This limited testing for a complex set of standards means you'll often encounter problems if you try anything that's not in </p&

15、gt;<p>　　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,

16、 has helped establish a basic level of compatibility among stacks, but the benefits have been limited because of the small number of configurations tested.</p><p>　　WS-I Basic Security Profile</p><

17、;p>　　From 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 spe

18、cified 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 sta

19、cks support some sets of choices well, others poorly, and still othe</p><p>　　Choice overload was such a problem in the early years of SOAP that an industry-wide group was created for the specific purpose of

20、 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 cho

21、ices 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.</p><p>　　Security is one of the areas WS-I ha

22、s 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

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

24、 few of its requirements</p><p>　　When you use digital signatures, BSP 1.1 requires you to follow the W3C Exclusive Canonicalization Recommendation, an XML canonicalization algorithm that ignores comments an

25、d unnecessary context information (see Resources). 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 is not specify a d

26、ifferent canonicalization algorithm (such as <sp:InclusiveC14N>).</p><p>　　BSP 1.1 also adds some other requirements for both signatures and encryption that constrain the algorithm-suite values de

27、fined 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 offere

28、d by WS-SecurityPolicy). Other BSP recommendations restrict how various security tokens are to be referenced and used.</p><p>　　The WS-I BSP has undoubtedly contributed to interoperability across web service

29、 security implementations, but aside from these minor points, it hasn't done anything toward reducing the complexity of security-configuration choices. An updated version of the BSP that was more-specifically oriente

30、d 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 in</p><

31、;p>　　Interoperability tests</p><p>　　Vendor-driven interoperability testing across stacks has been a more significant factor in improving the quality of web service security implementations. Microsoft

32、4; 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 participa

33、te in testing various scenarios between their code and the Microsoft implementation (see Resources). Security has been a major f</p><p>　　This interoperability testing has helped establish a basic level

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

35、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.</p><p>　　Security issues and limita

36、tions</p><p>　　In this column series, I've tested a variety of security configurations on three web services stacks, finding several issues with each stack. Limited interoperability testing (using one st

37、ack 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 the

38、se issues have been reported to the developers for each stack, and some have been fixed in t</p><p>　　Axis2 issues</p><p>　　The problems I found with Axis2 include WS-SecureConversation policy h

39、andling, 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, it's only compatible with ot

40、her stacks using that same configuration.</p><p>　　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

41、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.</p><p>　　Ax

42、is2 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 incompatibiliti

43、es 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.</p><

44、p>　　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 c

45、ommitters) 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 co

46、mponent, and Axis2 releases have been made that do not work with th</p><p>　　None of the significant Axis2 problems I found in writing these articles has been corrected as of the latest Axis2 and Rampart rel

47、eases.</p><p>　　Metro issues</p><p>　　Tests for the articles in this series also revealed some significant problems with Metro. The biggest problem is Metro's handling of signing message bod

48、ies. If the policy includes a OnlySignEntireHeadersAndBody assertion, everything is fine, but if this assertion isn't used, Metro incorrectly signs the content of the body, rather than the body element itse

49、lf. Stacks that handle the signing correctly will reject messages signed in this way by Metro.</p><p>　　Metro also broke with the WS-SecureConversation policy used in "WS-Trust and WS-SecureConversation

50、." 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 th

51、is and just used a single algorithm suite for both. This is not as significant a problem as the signing issue, in that there's little reason to use two different algorithm suites in pract</p><p>　　Finall

52、y, 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.</p><p&

53、gt;　　CXF issues</p><p>　　Just 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

54、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.</p>

55、<p>　　Comparing the stacks</p><p>　　Any attempt to rank web services stacks on their security support will necessarily be highly subjective, because each stack has both strengths and weaknesses. In tr

56、ying to give a balanced assessment, I've 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:</p><p>　　Correctness: How man

57、y implementation errors are known, and how serious are the errors?</p><p>　　Completeness: How complete is the security implementation?</p><p>　　Performance: How much overhead does the security h

58、andling add?</p><p>　　Usability: How easy is it to configure the security code?</p><p>　　Correctness</p><p>　　Axis2 has some significant problems, and the disconnect between the cor

59、e code and the Rampart security module is an issue of concern, but overall it seems fairly solid. Score: Axis2 — 6.</p><p>　　Metro has some major issues, in particular the incorrect handling of signatur

60、es when used without<sp:OnlySignEntireHeadersAndBody/>. 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 w

61、ith Axis2. Score: Metro — 7.</p><p>　　CXF has only relatively minor known issues, and the fast responses to problems and quick release cycle mean problems generally are corrected soon after they're

62、found. Score: CXF — 8.</p><p>　　To be fair on this point, I've only considered problems experienced directly in the course of these articles. Checking the bug-tracking systems for the stacks will sh

63、ow 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 it's a worthwhile exercise if you're considering sta

64、ndardizing on a particular stack. See Resources for information on the bug-tracking systems for the three stacks.</p><p>　　Completeness</p><p>　　All three stacks provide support for al

65、l 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 ver

66、sion released in 2007. For WS-SecureConversation, Axis2 implements a "canned" configuration, ignoring any policy configuration you supply. Scores: Axis2 — 6; Metro — 7; CXF — 7.</p><p>　　Perfo

67、rmance</p><p>　　Axis2 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 C

68、XF. Metro is slightly faster than CXF overall, so for this factor my scores are: Axis2 — 4; Metro — 8; CXF — 7.</p><p><b>　　Usability</b></p><p>　　Axis2's security configura

69、tion 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

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

71、anything it doesn't understand in </p><p>　　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 refere

72、nce 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

73、 configuring and using security features outside of the NetBeans/Glassfish bundle. Finally, in my experience, the error m</p><p>　　CXF has the cleanest approach to configuration, normally using separate file

74、s 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 extern

75、al 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 c</p><

76、p>　　Table 1 summarizes my rankings:</p><p>　　Table 1. Web service stack rankings</p><p>　　These rankings are not intended to be definitive, so if you are using them in making a decision about

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

78、own security code and other extensions (as is the case with IBM's WebSphere web services support, which is based on the Axis2 runtime but uses entirely different security code). Y</p><p>　　Wrapping up<

79、;/p><p>　　All 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

80、this article, you've 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.</p><p>　　The next article in the series takes a

81、 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.</p><p>　　——from IBM document library&l

82、t;/p><p>　　Java web 服務(wù): web 服務(wù)安全性狀態(tài)</p><p>　　所有主要 web 服務(wù)棧都為 WS-Security 和相關(guān) web 服務(wù)安全性標(biāo)準(zhǔn)提供一定程度的支持。我在本系列中介紹的 3 個開源棧 — Apache Axis2、Sun/Oracle Metro 和 Apache CXF — 都為這些標(biāo)準(zhǔn)提供相當(dāng)高級別的支持。但是它們的支持在許多方面有極大的差別，

83、包括安全性操作和使用運(yùn)行時安全性參數(shù)配置棧的方法。</p><p><b>　　關(guān)于本系列</b></p><p>　　Web Services 是企業(yè)計(jì)算中 Java 技術(shù)的重要組成部分。在本系列文章中，XML 和 Web 服務(wù)咨詢師 Dennis Sosnoski 介紹了兩個對于使用 Web Services 的 Java 開發(fā)人員來說非常重要的主流框架和技術(shù)。閱

84、讀本系列文章來了解這個領(lǐng)域的最新開發(fā)動態(tài)，并了解您可以如何使用它們來幫助您的編程項(xiàng)目。</p><p>　　一個重要的不同之處就是安全性實(shí)現(xiàn)的完整性和正確性。WS-Security 和 WS-SecurityPolicy 支持各種安全性配置，包括各種類型的密鑰和證書、算法套件、安全性令牌、以及簽名/加密規(guī)范。WS-Trust 和 WS-SecureConversation 進(jìn)一步擴(kuò)大選擇數(shù)目。這么多的可行配置，沒

85、有 web 服務(wù)棧能將它們?nèi)繙y試。即使測試每個孤立選項(xiàng)值都是相當(dāng)困難的，多數(shù)棧不會去嘗試。</p><p>　　在本文中，您將首先更多地了解 web 服務(wù)棧之間互操作性的安全問題。然后您將看到我根據(jù)自己對本系列近期 10 余篇文章進(jìn)行的研究，從正確性和可用性幾個方面比較 Axis2、Metro 和 CXF 之間的不同。</p><p><b>　　安全互操作性</b>

86、;</p><p>　　安全性標(biāo)準(zhǔn)為綜合測試提供很多選項(xiàng)組合。很多標(biāo)準(zhǔn)只提供少許這方面的示例，幾乎沒有什么測試套件，因此符合 “標(biāo)準(zhǔn)” 通常只是猜測，仁者見仁智者見智。結(jié)果聲明支持特定標(biāo)準(zhǔn)的棧很少驗(yàn)證它們的支持。</p><p>　　對于每個棧而言，不要試著根據(jù)標(biāo)準(zhǔn)進(jìn)行測試，而是使用一定數(shù)目的安全性配置對棧本身進(jìn)行測試，以及使用更少數(shù)量的互操作性配置測試它與其他棧之間的互操作性。除此之外，

87、每個棧的開發(fā)人員響應(yīng)源自用戶遇到的安全性配置或者互操作性問題的 bug 報(bào)告。復(fù)雜標(biāo)準(zhǔn)集的這個有限測試意味著，如果您嘗試一些非主流問題，可能會經(jīng)常遇到問題。盡管在本系列文章中，關(guān)于對安全性討論和性能比較進(jìn)行測試的安全性配置的數(shù)目較少，但我還是發(fā)現(xiàn)了這種類型的幾個問題。</p><p>　　業(yè)界為提高 web 服務(wù)安全性代碼質(zhì)量做了很多努力，包括業(yè)內(nèi)組織機(jī)構(gòu)的工作和供應(yīng)商驅(qū)動的互操作性測試。特別是后者，有助于在棧之

88、間建立基本的兼容性，但是收效甚微，因?yàn)闇y試配置的數(shù)量很少。</p><p>　　WS-I Basic Security Profile</p><p>　　從一開始，SOAP web 服務(wù)規(guī)范就為實(shí)施者和用戶提供了很多選擇。部分是有計(jì)劃的。其他的是由于標(biāo)準(zhǔn)疏忽造成的：預(yù)期的行為規(guī)定的不夠詳細(xì)，因此實(shí)施者不得不猜測哪些工作是需要完成的。過多的選擇帶來的問題是實(shí)施者缺乏資源來完全測試可能的組合

89、，因此，web 服務(wù)棧能很好地支持部分選擇，而對其他選擇支持較弱，甚至根本不支持。這種情況造成嚴(yán)重的可互操作性問題，因?yàn)椴荒鼙ＷC各種?？梢灾С窒嗤倪x擇。</p><p>　　在早年的 SOAP 中，選擇過量就是這類問題，業(yè)內(nèi)創(chuàng)建了一個行業(yè)級組專門限制可能的配置數(shù)量，方法是通過定義“最佳實(shí)踐” 的方法。這個小組，Web Services Interoperability Organization (WS-I)，生

90、成大量需要使用或者避免的特定選擇的配置文件（見 參考資料）。通過這些配置文件，WS-I 對形成當(dāng)前第三代 web 服務(wù)棧有很大影響。</p><p>　　在配置文件中安全性是 WS-I 所涉及的領(lǐng)域之一。WS-I Basic Security Profile Version 1.1（被稱為 BSP 1.1）是安全領(lǐng)域目前主要的文檔。該文檔包含廣泛的需求，但是與 WSI 的焦點(diǎn)保持一致，這些需求中大多數(shù)可

91、以處理 web 服務(wù)棧實(shí)現(xiàn)，但不能處理終端用戶安全性配置。BSP 1.1 完全不能處理 WS-SecurityPolicy 中的 WS-Security 配置，但是其少量需求可以轉(zhuǎn)換成 WS-SecurityPolicy 條款。</p><p>　　當(dāng)您使用數(shù)字簽名時，BSP 1.1 要求您遵守 W3C Exclusive Canonicalization Recommendation — 一個 XML 規(guī)范化算

92、法，忽略注釋和多余的上下文信息（見 參考資料）。在沒有任何選擇的情況下，該算法默認(rèn)由 WS-SecurityPolicy 承擔(dān)，因此，滿足這類需求您所要做的是不要 指定一個不同的規(guī)范化算法（比如 <sp:InclusiveC14N>）。</p><p>　　BSP 1.1 也添加了一些其他需求用于簽名和加密，約束 WS-SecurityProfile 中定義的算法套件值，

93、但本質(zhì)上只限制那些使用 TripleDes、Aes128 或 Aes256 加密和 SHA1 摘要（不包括 WS-SecurityPolicy 提供的 Aes192 加密和 SHA256 摘要）的選項(xiàng)。其他 BPS 建議限制各種安全令牌的引用和使用方法。</p><p>　　毋庸置疑，WS-I BSP 對跨 web 服務(wù)安全性實(shí)現(xiàn)的互操作性做出了貢獻(xiàn)，但是也有一些小問題，它未采取措施來減少安全配置選項(xiàng)的復(fù)雜性。B

94、SP 的一個更新版，更具體地說是面向 WS-SecurityPolicy 配置的更新版，對于使用現(xiàn)代基于策略的配置構(gòu)建安全性架構(gòu)的最佳實(shí)踐很有幫助，但很遺憾，WS-I 對這類更新并不感興趣。</p><p><b>　　互操作性測試</b></p><p>　　供應(yīng)商驅(qū)動的跨?；ゲ僮餍詼y試成為提高 web 服務(wù)安全性實(shí)現(xiàn)的一個很重要的因素。Microsoft®

95、; 已經(jīng)成為這個領(lǐng)域的推動力，在大學(xué)校園里舉辦一系列 “互操作性接插集會（plug-fests）”，邀請其他 web 服務(wù)棧（包括商業(yè)的和開源的）的開發(fā)人員來參與測試他們代碼和 Microsoft 實(shí)現(xiàn)之間的各種場景（見 參考資料）。安全性已經(jīng)成為接插集會主要關(guān)注的焦點(diǎn)。</p><p>　　這個互操作性測試有助于在各個棧之間建立基本水平的兼容性，但是收效甚微，因?yàn)橹挥猩倭颗渲帽粶y試。盡管通過 Micr

96、osoft 實(shí)現(xiàn)（而不是一個基于實(shí)際標(biāo)準(zhǔn)的測試套件）關(guān)注互操作性有一定的局限性，但是實(shí)際上，比起十幾個棧之間的完全交叉兼容性測試，這是很容易處理的。</p><p><b>　　安全性問題和局限性</b></p><p>　　在這個系列專欄中，我在 3 個 web 棧中測試了各種安全性配置，對于每個棧都找到了幾個問題。有限的互操作性測試（每個客戶端使用一個棧，服務(wù)器使

97、用另一個，只嘗試 WS-SecureConversation 測試）會顯示更多的問題。就拿棧 Apache Axis2 來說，我也發(fā)現(xiàn)了重大的性能問題。所有這些問題已經(jīng)報(bào)告給各個棧的開發(fā)人員了，其中一些在新版本中已經(jīng)得到修復(fù)了。在這一小節(jié)，我將從我為這些文章所作的測試方面，總結(jié) 3 個棧的目前狀態(tài)。</p><p><b>　　Axis2 問題</b></p><p>

98、;　　我在 Axis2 中發(fā)現(xiàn)的問題包括 WS-SecureConversation 策略處理，其中引導(dǎo)程序策略定義在運(yùn)行過程中似乎被完全忽略了。這意味著 Axis2 為其 WS-SecureConversation 支持使用千篇一律的配置，它只與其他使用相同配置的?？杉嫒?。</p><p>　　就安全性運(yùn)行時而言，Axis2 一個主要問題是對稱捆綁的客戶端處理（正如在 “不使用客戶端證書的 WS-Securit

99、y” 一文中所討論的）。當(dāng)發(fā)出更多的請求時，客戶端運(yùn)行逐漸減慢。我認(rèn)為這是一個很難的 bug，而不是一個性能問題，因?yàn)閱栴}有不斷發(fā)展的天性。</p><p>　　在任何時候只要使用安全性，操作就會逐步減慢（參見 “CXF 性能比較” 尋找原因 ），Axis2 安全性處理也深受其苦。這個性能問題似乎源自 Axis2 所用的 AXIOM 對象模型和安全性代碼所用的標(biāo)準(zhǔn) DOM 的不兼容性，因此問題可能會延續(xù)，除非增強(qiáng)

100、 AXIOM 來提供完整的 DOM 兼容性。</p><p>　　最后，在我看來，Axis2 可能會遭遇核心 web 服務(wù)引擎（實(shí)際是 Axis2 代碼）與安全性代碼（Rampart 和 Rahas 安全模塊）的分離。早在我們（Axis2 提交者）決定將安全性代碼從核心代碼分離出來時，就允許這些組件各自增強(qiáng)和發(fā)布。不幸的是，這導(dǎo)致安全性代碼被當(dāng)作一個可選組件，而且 Axis2 版本并不與當(dāng)時的 Rampart 版