Chính sách ký và mã hóa

Question

Tôi cần triển khai ứng dụng khách jax-ws.

Đây là những gì các tài liệu cung cấp nói về an ninh

Hiện nay, chúng tôi sử dụng SOAP Message Security phiên bản 1.0 đặc điểm kỹ thuật tại http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Tiêu chuẩn này sử dụng hai khác từ mức W3C:
XMLENC (http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/)
và XMLDSIG (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/)

Để ký, một "SecurityTokenReference" sử dụng một "tham chiếu" trực tiếp chỉ định "URI" và "valueType" của X509 là bắt buộc. Đối với mã hóa , chúng tôi cũng khuyên bạn nên sử dụng mã hóa, nhưng chúng tôi cũng hỗ trợ theo thứ tự tùy chọn tham chiếu đến khóa người định danh, tên X509IssuerSerial hoặc .

Khối được mã hóa và đã ký phải là thẻ “body”.

Chúng tôi khuyên bạn nên sử dụng: “rsa-sha1” để ký, “rsa-1_5” cho khóa mã hóa và “tripledes-cbc” để mã hóa nội dung.

Vì vậy, tôi đã đưa ra chính sách sau (được tạo từ netbeans). Nhưng ... nó không nhìn thẳng vào tôi. Dịch vụ web không thể truy cập được, nhưng tôi không chắc chắn rằng các phiên bản thông số phù hợp. Tôi đọc rất nhiều về chủ đề này, nhưng tôi vẫn còn hơi bối rối. Chính sách này có ổn không?

<wsp1:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoapPolicy"> 
    <wsp1:ExactlyOne> 
     <wsp1:All> 
      <sp:TransportBinding> 
       <wsp1:Policy> 
        <sp:TransportToken> 
         <wsp1:Policy> 
          <sp:HttpsToken RequireClientCertificate="false"/> 
         </wsp1:Policy> 
        </sp:TransportToken> 
        <sp:Layout> 
         <wsp1:Policy> 
          <sp:Lax/> 
         </wsp1:Policy> 
        </sp:Layout> 
        <sp:AlgorithmSuite> 
         <wsp1:Policy> 
          <sp:TripleDesRsa15/> 
         </wsp1:Policy> 
        </sp:AlgorithmSuite> 
       </wsp1:Policy> 
      </sp:TransportBinding> 
      <sp:Wss10/> 
      <sp:EndorsingSupportingTokens> 
       <wsp1:Policy> 
        <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"> 
         <wsp1:Policy> 
          <sp:WssX509V3Token10/> 
         </wsp1:Policy> 
        </sp:X509Token> 
       </wsp1:Policy> 
      </sp:EndorsingSupportingTokens> 

     </wsp1:All> 
    </wsp1:ExactlyOne> 
</wsp1:Policy> 
<wsp:Policy wsu:Id="ListeOperationsPeriodeSoapBindingSoap_perform_Input_Policy"> 
    <wsp:ExactlyOne> 
     <wsp:All> 
      <sp1:SignedEncryptedSupportingTokens> 
       <wsp:Policy> 
        <sp1:X509Token sp1:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient"> 
         <wsp:Policy> 
          <sp1:WssX509V3Token10/> 
         </wsp:Policy> 
        </sp1:X509Token> 
       </wsp:Policy> 
      </sp1:SignedEncryptedSupportingTokens> 
     </wsp:All> 
    </wsp:ExactlyOne> 

</wsp:Policy> 

CHỈNH SỬA: Tôi không thể gửi thư được mong đợi bằng witit. Ví dụ, bằng cách sử dụng thuật sĩ Netbeans, tôi không thể nhận được một tiêu đề được mã hóa mà không sử dụng địa chỉ. Nó có thể là có thể?

Tôi đã hack thứ gì đó với lớp trục 1 cũ và wss4j, nó hoạt động nhưng nó xấu xí và tôi muốn sử dụng thứ gì đó tương lai hơn.

Answer 1

Có thể bạn muốn thử với CXF thay vì WSIT? http://cxf.apache.org/docs/ws-security.html

Answer 2

Bạn có vẻ bối rối. Nói chung, bạn nên có một chính sách duy nhất. Trong trường hợp của bạn, bạn có nguy cơ chấp nhận các cuộc gọi dịch vụ web không an toàn bởi vì bạn có một chính sách xác định ràng buộc vận chuyển (https), trong khi cái kia thì không.

Ngoài ra, vì bạn có một ràng buộc vận chuyển, điều đó có nghĩa là toàn bộ cơ thể sẽ được mã hóa bằng giao thức truyền tải (https). Bạn không cần phải xác định mã hóa cơ thể một cách rõ ràng. Trong thực tế, ràng buộc này sẽ mã hóa mọi thứ ngoại trừ tiêu đề http.

Ràng buộc vận chuyển thực sự là cách dễ nhất để nhận các dịch vụ web bảo mật. Nếu bạn muốn kiểm soát toàn bộ, bạn phải viết liên kết đối xứng hoặc đối xứng riêng của bạn tùy thuộc vào nhu cầu của bạn. Asymetric phức tạp hơn vì nó đòi hỏi một chứng chỉ trên cả hai mặt, trong khi asymetric chỉ yêu cầu chứng chỉ máy chủ (chấp nhận các máy khách ẩn danh). Các ràng buộc đối xứng và đối xứng đòi hỏi sự quan tâm. Chúng được thiết kế rất linh hoạt và sẽ cho phép bạn thiết kế bất kỳ chính sách nào, ngay cả khi dễ bị tấn công nhất định.

Khi không sử dụng liên kết vận chuyển, thì bạn phải chỉ định nội dung phải được mã hóa.Như đã nêu trong thông số kỹ thuật:

sp:EncryptedParts/sp:Body 

Hoặc dịch sang xml:

<sp:EncryptedParts> 
    <sp:Body/> 
</sp:EncryptedParts> 

Tương tự như vậy, nếu bạn muốn cơ thể sẽ được ký kết:

<sp:SignedParts> 
    <sp:Body/> 
</sp:SignedParts> 

Có thêm nhiều lựa chọn để xác định chữ ký/thứ tự mã hóa, cho dù mã hóa chữ ký hay không, v.v.

Như tên gọi, policie s chẳng hạn như sp: EndorsingSupportingToken áp dụng cho mã thông báo hỗ trợ. Loại tôi quen thuộc là mã thông báo tên người dùng mà bạn có thể đưa vào bên trong yêu cầu dịch vụ web.

WS-SecurityPolicy specification là tài liệu hữu ích nhất mà tôi đã đọc để hiểu chính sách. Bạn nên dành thời gian để đọc kỹ. Nó chi tiết những điều khá tốt và chứa các ví dụ hữu ích. Nó là tốt để đọc các phiên bản khác nhau của các tài liệu vì một số khía cạnh sẽ được tài liệu tốt hơn trong các phiên bản gần đây. Lưu ý tôi đã liên kết v1.3.

Thiết lập máy khách và dịch vụ web và viết các kiểm tra đơn giản. Đặc biệt là nếu bạn chưa quen với dịch vụ web.

Một công cụ sẽ giúp bạn xây dựng chính sách nhanh chóng là SoapUI. Nó không hỗ trợ chính xác những gì tôi cần nhưng nó đã giúp tôi học một vài điều. Nó có một giao diện người dùng tuyệt vời và nó không phải là rất khó sử dụng.

Lấy một số ví dụ hoặc xây dựng một số ví dụ, sau đó giải mã chúng với sự trợ giúp của đặc điểm kỹ thuật.

Tôi đã tìm thấy các chính sách khá phức tạp. Hãy chuẩn bị để hấp thụ rất nhiều khái niệm!