Các dịch vụ Web Java: Tình trạng bảo mật dịch vụ web

Tìm hiểu hiện trạng xử lý bảo mật trong các chồng các dịch vụ web Java nguồn mở

WS-Security và các tiêu chuẩn có liên quan cung cấp một dải rộng các tùy chọn về bảo mật dịch vụ web. Trong dải rộng này, các chồng/ngăn xếp các dịch vụ web chỉ tự kiểm tra một số lượng hạn chế các cấu hình bảo mật và thậm chí còn ít cấu hình hơn về tính tương thích. Hãy tìm hiểu những gì ngành công nghiệp phần mềm đã thực hiện để thúc đẩy tính tương thích giữa các chồng/ngăn xếp các dịch vụ web và xem một so sánh tóm tắt về ba chồng/ngăn xếp Java™ nguồn mở xử lý bảo mật như thế nào.

Dennis Sosnoski, Nhà tư vấn, Sosnoski Software Solutions, Inc.

Dennis Sosnoski là một nhà tư vấn và nhà trợ giúp đào tạo chuyên về các dịch vụ Web và SOA dựa trên-Java. Kinh nghiệm phát triển phần mềm chuyên nghiệp của ông trải suốt hơn 30 năm qua, với một thập kỉ cuối tập trung vào các công nghệ XML và Java phía máy chủ. Dennis là nhà phát triển hàng đầu về dụng cụ liên kết dữ liệu XML JiBX mã nguồn mở, cũng là một người có duyên nợ với khung công tác của các dịch vụ Web Apache Axis2. Ông cũng là một trong những thành viên của nhóm chuyên gia đặc tả kỹ thuật của Jax-WS 2.0 và JAXB 2.0. Xem trang web của ông để có thông tin về các dịch vụ đào tạo và tư vấn của ông.



29 06 2012

Tất cả các chồng các dịch vụ web chính đều cung cấp một số mức hỗ trợ cho WS-Security và các tiêu chuẩn bảo mật các dịch vụ web liên quan. Tất cả ba chồng nguồn mở mà tôi đã trình bày trong loạt bài này — Apache Axis2, Sun/Oracle Metro và Apache CXF — đều cung cấp một mức hỗ trợ khá cao cho các tiêu chuẩn này. Nhưng sự hỗ trợ của chúng khác nhau đáng kể theo nhiều cách, gồm cả hoạt động bảo mật lẫn cách các chồng được cấu hình với các tham số bảo mật thời gian chạy ra sao.

Giới thiệu về loạt bài này

Các dịch vụ Web là một phần quan trọng về vai trò của công nghệ Java™ trong điện toán doanh nghiệp. Trong loạt bài này, nhà tư vấn các dịch vụ web và XML Dennis Sosnoski trình bày các khung công tác và các công nghệ chính rất quan trọng cho các nhà phát triển Java đang sử dụng các dịch vụ web. Hãy theo dõi loạt bài này để cập nhật những phát triển mới nhất trong lĩnh vực này và hiểu rõ cách bạn có thể sử dụng chúng để hỗ trợ cho các dự án lập trình của mình.

Một lĩnh vực quan trọng khác liên quan đến tính đầy đủ và tính chính xác của các công cụ bảo mật. WS-Security và WS-SecurityPolicy cho phép nhiều biến thể của các cấu hình bảo mật, bao gồm các kiểu khóa và các chứng nhận khác nhau, các bộ thuật toán, các thẻ xác thực bảo mật và các đặc tả ký/mã hóa. WS-Trust và WS-SecureConversation mở rộng số lượng các lựa chọn hơn nữa. Với nhiều cấu hình tiềm năng như thế, không có chồng/ngăn xếp các dịch vụ web nào có thể kiểm tra tất cả chúng. Ngay cả việc kiểm tra riêng từng giá trị tùy chọn có thể rất khó và hầu hết các chồng không thực hiện được.

Trong bài này, trước tiên bạn sẽ tìm hiểu thêm về các vấn đề về tính tương thích bảo mật giữa các chồng các dịch vụ web. Sau đó, bạn thấy cách Axis2, Metro và CXF so sánh căn cứ vào một số biện pháp về tính chính xác và tính dễ sử dụng, dựa trên nghiên cứu của tôi trong một tá các bài gần đây hoặc hơn một chút về loạt bài này.

Tính tương thích bảo mật

Các tiêu chuẩn bảo mật cung cấp rất nhiều tổ hợp tùy chọn để kiểm tra toàn diện. Phần lớn các tiêu chuẩn cung cấp rất ít trong các ví dụ và không có thứ gì về các bộ kiểm tra, vì thế việc tuân thủ "tiêu chuẩn" thường là một vấn đề về dư luận và phỏng đoán. Kết quả là, các chồng yêu cầu hỗ trợ một tiêu chuẩn cụ thể hiếm khi thực hiện bất cứ việc xác minh mở rộng nào về sự hỗ trợ của chúng.

Thay vì cố gắng kiểm tra theo tiêu chuẩn, mỗi chồng sử dụng một số lượng hạn chế các cấu hình bảo mật cho việc kiểm tra riêng của mình, cùng với một số lượng hạn chế hơn nữa các cấu hình trong các bài kiểm tra tính tương thích với các chồng khác. Khác hơn thế, với mỗi chồng các nhà phát triển trả lời các báo cáo lỗi của người dùng đang gặp phải các vấn đề về cấu hình bảo mật hoặc tính tương thích. Việc kiểm tra hạn chế này theo một bộ các tiêu chuẩn phức tạp có nghĩa là bạn sẽ thường gặp phải các vấn đề nếu bạn cố gắng làm bất cứ điều gì không có trong luồng chính. Ngay chỉ với số lượng tương đối nhỏ của các cấu hình bảo mật được kiểm tra dành cho cuộc thảo luận bảo mật và các so sánh hiệu năng trong các bài của loạt bài này, tôi đã thấy một số vấn đề thuộc loại này.

Một số nỗ lực để cải thiện chất lượng của mã bảo mật các dịch vụ web đã được thực hiện, gồm cả công việc của một tổ chức toàn ngành công nghiệp phần mềm và việc kiểm tra tính tương thích dựa vào nhà cung cấp. Cụ thể, cái sau đã giúp thiết lập một mức tương thích cơ bản giữa các chồng, nhưng các lợi ích đã bị hạn chế do số lượng các cấu hình được kiểm tra rất ít.

WS-I Basic Security Profile (Lược tả bảo mật cơ bản của WS-I)

Ngay từ đầu, các đặc tả các dịch vụ web SOAP đã cung cấp nhiều sự lựa chọn cho những người triển khai thực hiện và những người sử dụng. Điều này có phần do cố ý. Các trường hợp khác do các sơ suất trong các tiêu chuẩn: Các hành vi dự kiến chưa được ghi rõ đủ chi tiết, do đó, những người triển khai thực hiện đã phải phỏng đoán những gì cần làm. Vấn đề có quá nhiều lựa chọn làm cho những người triển khai thực hiện thiếu tài nguyên để kiểm tra đầy đủ tất cả các tổ hợp có thể có, do đó các chồng các dịch vụ web hỗ trợ tốt một số bộ các lựa chọn, các chồng khác thì kém hơn và vẫn còn những chồng khác không hỗ trợ chút nào. Tình hình này tạo ra các vấn đề lớn về tính tương thích, bởi vì không có sự đảm bảo rằng các chồng khác cũng hỗ trợ các lựa chọn tương tự.

Quá tải chọn lựa đã là một vấn đề như vậy trong những năm đầu của SOAP, do một nhóm toàn ngành công nghiệp phần mềm đã tạo ra với mục đích cụ thể về hạn chế số lượng các cấu hình có thể bằng cách định nghĩa các cách tiếp cận "các cách thực hành tốt nhất". Nhóm này, tổ chức WS-I (Tính tương thích các Dịch vụ Web), đã đưa ra một số các lược tả yêu cầu sử dụng hoặc tránh xa các lựa chọn đặc biệt (xem Tài nguyên). Thông qua các lược tả này, WS-I đã có một ảnh hưởng lớn trong việc định hình thế hệ thứ ba của các chồng các dịch vụ web.

Bảo mật là một trong những lĩnh vực mà WS-I đã trình bày trong các lược tả. Phiên bản 1.1 của WS-I Basic Security Profile (gọi tắt là BSP 1.1) là tài liệu chính hiện hành trong lĩnh vực bảo mật. Tài liệu này bao gồm một loạt các yêu cầu, nhưng phù hợp với trọng tâm của WS-I, hầu hết các yêu cầu này đều đề cập đến các việc triển khai thực hiện chồng các dịch vụ web chứ không phải là cấu hình bảo mật của người dùng cuối. BSP 1.1 cũng không đề cập đến các cấu hình WS-Security trong WS-SecurityPolicy, nhưng một vài yêu cầu của nó có thể được chuyển sang các thuật ngữ của WS-SecurityPolicy.

Khi bạn sử dụng chữ ký số, BSP 1.1 đòi hỏi bạn phải thực hiện theo W3C Exclusive Canonicalization Recommendation (Khuyến cáo về chính tắc hóa độc quyền của W3C), một thuật toán chính tắc hóa XML bỏ qua các nhận xét và thông tin ngữ cảnh không cần thiết (xem Tài nguyên). Thuật toán này là mặc định được WS-SecurityPolicy giả định trong khi không có bất kỳ sự lựa chọn nào, do đó tất cả mọi thứ mà bạn cần làm để đáp ứng yêu cầu này là không chỉ rõ một thuật toán chính tắc hóa khác (ví dụ như <sp:InclusiveC14N>).

BSP 1.1 cũng thêm một số yêu cầu khác cho cả hai các chữ ký và mã hóa, ràng buộc các giá trị của bộ-thuật toán được định nghĩa trong WS-SecurityProfile, nhưng về cơ bản các giá trị này chỉ hạn chế các lựa chọn với các chữ ký và mã hóa nào sử dụng mã hóa TripleDES, AES128 hoặc AES256 và thuật toán băm SHA1 (chỉ không bao gồm các tùy chọn mã hóa Aes192 và thuật toán băm SHA256 do WS-SecurityPolicy cung cấp). Các khuyến cáo BSP khác hạn chế cách tham khảo và sử dụng các thẻ xác nhận bảo mật khác nhau.

BSP của WS-I chắc chắn đã góp phần vào tính tương thích qua các triển khai thực hiện bảo mật dịch vụ web, nhưng ngoài các điểm nhỏ này, nó đã không làm bất cứ việc gì nhằm làm giảm tính phức tạp của các lựa chọn cấu hình-bảo mật. Một phiên bản cập nhật của BSP, đã được định hướng rõ ràng nhằm tới các cấu hình WS-SecurityPolicy, sẽ rất có ích để giúp thiết lập các cách thực hành tốt nhất cho các kiến trúc sư bảo mật khi sử dụng các cấu hình dựa trên chính sách hiện đại, nhưng đáng tiếc là WS-I đã không tỏ rõ sự quan tâm trong bản cập nhật này.

Các bài kiểm tra tính tương thích

Việc kiểm tra tính tương thích dựa vào nhà cung cấp qua các chồng là một nhân tố quan trọng hơn trong việc cải thiện chất lượng của các công cụ bảo mật dịch vụ web. Microsoft® đã là một động lực thúc đẩy trong lĩnh vực này, lưu trữ một loạt "các plug-fest về tính tương thích" tại cơ sở của mình, nơi các nhà phát triển các chồng các dịch vụ web khác (cả thương mại lẫn nguồn mở) được mời tham gia kiểm tra các kịch bản khác nhau giữa mã của họ và công cụ của Microsoft (xem Tài nguyên). Bảo mật đã là một trọng tâm chính của các plug-fest (bài kiểm tra tính tương thích của các thiết bị mạng).

Việc kiểm tra tính tương thích này đã giúp thiết lập một mức tương thích cơ bản giữa các chồng, nhưng các lợi ích đã bị hạn chế do chỉ có một số ít các các cấu hình được kiểm tra. Sự tập trung vào tính tương thích với công cụ của Microsoft (chứ không phải là một bộ kiểm tra dựa trên các tiêu chuẩn thực tế) cũng đã là một hạn chế rồi, mặc dù theo các thuật ngữ thực hành việc này còn dễ xử lý hơn nhiều so với các bài kiểm tra tính tương thích đầy đủ giữa một tá các chồng hay nhiều hơn.


Các vấn đề bảo mật và các hạn chế

Trong loạt cột báo này, tôi đã kiểm tra một loạt các cấu hình bảo mật trên cả 3 chồng các dịch vụ web, tìm ra một số vấn đề với từng chồng. Việc kiểm tra tính tương thích hạn chế (việc sử dụng một chồng cho máy khách và một chồng khác cho máy chủ, chỉ được dùng thử các bài kiểm tra WS-SecureConversation) đã chứng tỏ thêm nhiều vấn đề. Trong trường hợp của một chồng, Apache Axis2, tôi cũng đã thấy các vấn đề hiệu năng đáng kể. Tất cả những vấn đề này đã được báo cáo cho các nhà phát triển về mỗi chồng và một số chồng đã được sửa chữa trong các bản phát hành mới nhất. Trong phần này, tôi sẽ tóm tắt hiện trạng của ba chồng về việc kiểm tra mà tôi đã làm trong các bài này.

Các vấn đề của Axis2

Các vấn đề mà tôi đã thấy với Axis2 bao gồm việc xử lý chính sách của WS-SecureConversation, trong đó định nghĩa chính sách khởi động xem ra bị bỏ qua hoàn toàn trong hoạt động. Vì điều này có nghĩa là Axis2 sử dụng một cấu hình đóng gói để hỗ trợ WS-SecureConversation của mình, nó chỉ tương thích với các chồng khác khi sử dụng cùng một cấu hình đó.

Về thời gian chạy bảo mật, Axis2 có một vấn đề lớn trong việc xử lý phía máy khách về các liên kết đối xứng (như được thảo luận trong"WS-Security không có các chứng nhận máy khách"). Máy khách chạy ngày càng chậm dần khi thực hiện nhiều yêu cầu hơn. Tôi coi đây là một lỗi cứng, chứ không phải là một vấn đề hiệu năng, vì tính chất phát triển của vấn đề.

Việc xử lý bảo mật của Axis2 cũng bị quấy rầy do hoạt động luôn chạy chậm bất kỳ khi nào sử dụng bảo mật (xem"So sánh hiệu năng CXF" để biết một số kết quả). Vấn đề hiệu năng có vẻ như được bắt nguồn từ sự không tương thích giữa mô hình đối tượng AXIOM do Axis2 sử dụng và DOM tiêu chuẩn do mã bảo mật sử dụng, vì thế, các vấn đề này có thể tiếp tục cho đến khi và trừ khi AXIOM được nâng cao để cung cấp tính tương thích DOM đầy đủ.

Cuối cùng, theo ý kiến của tôi, Axis2 có xu hướng bị ngắt kết nối giữa công cụ các dịch vụ web cốt lõi (mã Axis2 thực tế) và mã bảo mật (các mô đun bảo mật Rampart và Rahas). Ban đầu chúng tôi (những người đóng góp hàng đầu cho Axis2) đã quyết định tách mã bảo mật khỏi mã cốt lõi, cho phép các thành phần này được nâng cao và phát hành riêng. Thật không may, điều này đã dẫn đến mã bảo mật vẫn được xử lý như là một thành phần tùy chọn và các bản phát hành Axis2 đã được tạo ra không làm việc với việc bản phát hành Rampart sau đó. Bản phát hành Axis2 1.5.2 gần đây là một ví dụ: bản phân phối mã nhị phân này thiếu một tệp JAR cần thiết để xử lý bảo mật, vì vậy không có cách nào dễ dàng để làm cho nó làm việc với Rampart. Điều này đã được chỉnh sửa trong bản phát hành hiện tại Axis2 1.5.3, nhưng sự thực, một bản phát hành chính thức sẽ phân phối mà không có hoạt động hỗ trợ bảo mật, biểu thị ngắt kết nối.

Không có vấn đề nào trong số các vấn đề Axis2 quan trọng, mà tôi đã thấy khi viết các bài này, đã được sửa chữa trong các bản phát hành Axis2 và Rampart mới nhất.

Các vấn đề của Metro

Các bài kiểm tra dành cho các bài viết trong loạt bài này cũng đã để lộ một số vấn đề quan trọng với Metro. Vấn đề lớn nhất là việc xử lý ký các phần thân thông báo của Metro. Nếu chính sách này gồm có một xác nhận <sp:OnlySignEntireHeadersAndBody/> tất cả mọi thứ là tốt, nhưng nếu xác nhận này không được sử dụng, thì Metro ký sai nội dung phần thân, chứ không phải là phần tử phần thân của nó. Các chồng xử lý việc ký đúng sẽ từ chối các thông báo được Metro ký theo cách này.

Metro cũng đã phá vỡ chính sách WS-SecureConversation được sử dụng trong "WS-Trust và WS-SecureConversation." Trong trường hợp này vấn đề là chính sách này đã sử dụng các bộ thuật toán khác nhau để trao đổi thông báo khởi động với Security Token Service (STS – Dịch vụ thẻ xác nhận bảo mật) và đàm thoại thực sự với dịch vụ đó. Metro đã bỏ qua điều này và chỉ sử dụng một bộ thuật toán duy nhất cho cả hai. Đây không phải là một vấn đề quan trọng như vấn đề ký, trong đó có ít lý do để sử dụng hai bộ thuật toán khác nhau trong thực hành, nhưng nó vẫn còn một lỗi.

Cuối cùng, Metro cũng đã có các vấn đề liên quan đến việc sử dụng mã hóa hoặc ký một chiều được báo cáo trong "Tìm hiểu về WS-Policy". Không có một vấn đề nào trong những vấn đề này đã được sửa chữa trong bản phát hành mới nhất của Metro.

Các vấn đề của CXF

Cũng như với các chồng khác, tôi đã thấy một số vấn đề của CXF trong khi kiểm tra với các bài này. Trong hầu hết các trường hợp, các vấn đề đã được sửa chữa trong một bản phát hành CXF mới trước khi bài này được xuất bản. Ngoại lệ duy nhất đối với các vấn đề này liên quan đến việc sử dụng mã hóa hoặc ký một chiều được báo cáo trong "Tìm hiểu về WS-Policy" — hiện đã được sửa chữa trong bản phát hành CXF 2.3.1.


So sánh các chồng

Bất kỳ nỗ lực nào để xếp hạng các chồng các dịch vụ web về mặt hỗ trợ bảo mật của chúng tất yếu sẽ rất chủ quan, bởi vì mỗi chồng đều có các điểm mạnh và các điểm yếu. Trong lúc cố gắng để đưa ra một đánh giá cân bằng, tôi đã chia việc xếp hạng này thành bốn nhân tố và đã gán một đánh giá số trong dải từ 1 đến 10 (xấu nhất đến tốt nhất) cổ điển cho mỗi chồng:

  • Tính chính xác: Có bao nhiêu nhiều lỗi thực hiện được biết đến và các lỗi nghiêm trọng đến mức nào?
  • Tính đầy đủ: Việc thực hiện bảo mật đủ tới mức nào?
  • Hiệu năng: Phải thêm bao nhiêu chi phí hoạt động nữa để xử lý bảo mật?
  • Tính dễ sử dụng: Cấu hình mã bảo mật dễ như thế nào?

Tính chính xác

Axis2 có một số vấn đề quan trọng và việc ngắt kết nối giữa mã cốt lõi và mô đun bảo mật Rampart là một vấn đề quan tâm, nhưng nói chung nó có vẻ khá vững chắc. Điểm số: Axis2 — 6.

Metro có một số vấn đề chính, cụ thể là việc xử lý sai các chữ ký khi được sử dụng mà không có xác nhận <sp:OnlySignEntireHeadersAndBody/>. Mặc dù, giống như Axis2, nói chung nó có vẻ khá vững chắc và sự tích hợp của mã bảo mật vào trong bản phát hành chính làm cho toàn bộ các lỗi có thể thấp hơn so với Axis2. Điểm số— 7.

CXF chỉ có các vấn đề đã biết tương đối nhỏ và trả lời nhanh với các vấn đề và chu kỳ phát hành nhanh có nghĩa là các vấn đề thường được sửa chữa ngay sau khi người ta tìm ra chúng. Điểm số: CXF — 8.

Để công bằng vào lúc này, tôi đã chỉ xem xét các vấn đề đã xảy ra trực tiếp trong những bài này. Việc kiểm tra các hệ thống dò tìm-lỗi cho các chồng sẽ hiển thị các vấn đề khác, có thể quan trọng hơn. Bạn cần sử dụng cẩn thận khi xem xét chúng — một số các vấn đề được báo cáo có thể do các lỗi do người dùng gây ra — nhưng đó là một hoạt động đáng giá nếu bạn đang xem xét việc tiêu chuẩn hóa trên một chồng cụ thể. Xem Tài nguyên để biết thông tin về các hệ thống dò tìm-lỗi cho ba chồng này.

Tính đầy đủ

Tất cả ba chồng đều đưa ra sự hỗ trợ cho tất cả các tiêu chuẩn bảo mật chính. Tuy nhiên, sự hỗ trợ của Axis2 bị hạn chế ít nhất trong hai khía cạnh. Đối với WS-Policy, việc tạo mã Axis2 chỉ làm việc với các phiên bản trình lên đã lỗi thời từ năm 2004, chứ không phải là phiên bản W3C tiêu chuẩn được phát hành vào năm 2007. Đối với WS-SecureConversation, Axis2 thực hiện một cấu hình "đóng gói", bỏ qua bất kỳ cấu hình chính sách nào mà bạn cung cấp. Các điểm số: Axis2 — 6; Metro — 7; CXF — 7.

Hiệu năng

Axis2 rõ ràng là kẻ thua cuộc khi nó tham gia vào bất kỳ các xếp hạng hiệu năng-bảo mật nào. Trong tất cả các hình thức xử lý bảo mật mức-thông báo, nó gây ra nhiều chi phí xử lý hơn so với Metro hoặc CXF. Metro nhanh hơn một chút so với CXF về tổng thể, do đó, với nhân tố này điểm số của tôi là: Axis2 — 4; Metro — 8; CXF — 7.

Tính dễ sử dụng

Cấu hình bảo mật của Axis2 hơi dở. Về phía máy khách, nó đòi hỏi bạn hoặc phải nhúng các tham số thời gian chạy vào WSDL dịch vụ hoặc phải cấu hình các tham số trực tiếp theo mã máy khách của bạn. Cả hai cách, bạn thực sự phải kích hoạt xử lý bảo mật trong mã máy khách của mình. Về phía máy chủ, bạn phải thay đổi tệp services.xml được tạo ra để bao gồm các tham số thời gian chạy và để kích hoạt xử lý bảo mật. Axis2 cũng có xu hướng âm thầm bỏ qua bất cứ điều gì mà nó không hiểu trong cấu hình chính sách. Điểm số: Axis2 — 5.

Có lẽ để làm việc với Metro dễ hơn một chút so với Axis2, nhưng nó luôn luôn yêu cầu bạn phải thêm các tham số thời gian chạy của mình vào WSDL dịch vụ (hoặc về phía máy khách, ít nhất là tham khảo một tài liệu riêng định nghĩa các tham số). Tôi cho rằng điều này là không phù hợp, vì WSDL được hỗ trợ để mô tả hợp đồng dịch vụ đã xuất bản. Metro cũng cung cấp một ít tài liệu về cấu hình và sử dụng các tính năng bảo mật bên ngoài gói NetBeans/Glassfish. Cuối cùng, theo kinh nghiệm của tôi, các thông báo lỗi, mà bạn nhận được khi có một vấn đề về cấu hình, có xu hướng khó hiểu, gây khó khăn cho việc dò tìm nguyên nhân. Điểm số: Metro — 6.

CXF có cách tiếp cận sạch nhất về cấu hình, thông thường sử dụng các tệp riêng cho các tham số bảo mật thời gian chạy trên cả máy khách và máy chủ. Bạn cũng có tùy chọn cấu hình mọi thứ trực tiếp khi sử dụng Spring hoặc trong mã của bạn. Ngoài các vấn đề cấu hình cơ bản, CXF cũng hỗ trợ các tài liệu tham khảo chính sách bên ngoài trong WSDL, một tính năng quan trọng đối với các tổ chức muốn chuẩn hóa các chính sách bảo mật trên toàn doanh nghiệp. Cuối cùng, CXF dường như có cách xử lý tốt nhất với các thành phần chính sách chưa được hỗ trợ, tạo ra các thông báo cảnh báo cho bạn biết rằng chính sách đó chưa được hỗ trợ đầy đủ. Điểm số: CXF — 8.

Bảng 1 tóm tắt các xếp hạng của tôi:

Bảng 1. Các xếp hạng chồng dịch vụ Web
Apache Axis2Sun/Oracle MetroApache CXF
Tính chính xác678
Tính đầy đủ677
Hiệu năng487
Tính dễ sử dụng568
Tổng cộng212830

Các xếp hạng này chưa phải là ý định cuối cùng, vì vậy nếu bạn đang sử dụng chúng trong việc đưa ra một quyết định về việc sử dụng một chồng riêng của mình, đừng quên xem xét các lý do của tôi và thực hiện phán quyết riêng của mình. Ngoài ra, các xếp hạng này chỉ áp dụng cho các dự án nguồn mở cơ sở; các chồng thương mại dựa trên các phiên bản nguồn mở có thể sử dụng mã bảo mật riêng của chúng và các phần mở rộng khác (như trường hợp có sự hỗ trợ các dịch vụ web WebSphere của IBM, dựa trên thời gian chạy Axis2 nhưng sử dụng mã bảo mật khác nhau hoàn toàn). Bạn sẽ cần xem xét các khác biệt giữa mã thương mại và cơ sở nguồn mở để xem có thể áp dụng những phần nào của các xếp hạng đó.


Tóm tắt

Tất cả ba chồng các dịch vụ web nguồn mở được xem xét trong loạt bài này đến bây giờ đều cung cấp sự hỗ trợ tốt cho các tính năng bảo mật. Mỗi chồng có một số điểm mạnh và điểm yếu trong lĩnh vực bảo mật và trong bài này, bạn đã thấy một bản tóm tắt về cách so sánh chúng dựa trên các trải nghiệm của tôi trong khi làm việc với ba chồng trong một tá các bài gần đây hoặc nhiều hơn một chút.

Bài tiếp theo trong loạt bài này có một chiến thuật khác, khi nghiên cứu sâu vào cấu trúc của các định nghĩa dịch vụ WSDL và phát triển một công cụ để xác minh các WSDL và chuyển đổi chúng thành các dạng mẫu các cách thực hành tốt nhất được khuyến cáo.

Tài nguyên

Học tập

Thảo luận

  • Hãy dành tâm trí cho cộng đồng My developerWorks. Kết nối với những người dùng developerWorks khác trong lúc khám phá các blog, các diễn đàn, các nhóm và các wiki hướng nhà phát triển.

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Khi bạn đăng ký với trang developerWorks lần đầu tiên, một tiểu sử của của bạn được tạo ra. Chọn các thông tin về tiểu sử của bạn (tên, nước/vùng, và nơi làm việc) đã được hiện lên màn hình, thông tin này sẽ được hiện kèm với nội dung mà bạn đăng tải. Bạn có thể cập nhật thông tin này bất kỳ lúc nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Công nghệ Java, SOA và dịch vụ Web, Nguồn mở
ArticleID=823435
ArticleTitle=Các dịch vụ Web Java: Tình trạng bảo mật dịch vụ web
publish-date=06292012