2010-11-20 29 views
5

Tôi đang phát triển một ứng dụng web sử dụng chứng chỉ ứng dụng khách để xác thực đối với Tomcat trong khi thực hiện các cuộc gọi dịch vụ web với Jersey. Điều này đang làm việc tuyệt vời cho đến nay, nhưng tôi cần một lối vào web trên cùng một bối cảnh mà sẽ cho phép tôi quản lý ứng dụng này. Vì cấu hình SSL là "theo ngữ cảnh", tùy chọn duy nhất để sử dụng giao diện người dùng https có vẻ như đang cài đặt chứng chỉ ứng dụng vào trình duyệt truy cập, được liệt kê trong kho tin của tomcat (hoặc là hủy hoặc sử dụng https hoàn toàn) .Định cấu hình việc sử dụng chứng chỉ HTTPS dựa trên url trong Tomcat

Để minh họa cho những gì tôi thực sự muốn:

1. https://url-to-webapp/ws <- Should use client certificate 
2. https://url-to-webapp/web <- Should just use a server certificate 

này có thể đạt được bằng cách nào đó trong cấu hình Tomcat, hoặc thậm chí trong các mã ứng dụng?

Cập nhật

Tôi đã thử các cấu hình được đề xuất bởi EJP nhưng bây giờ tôi không thể kết nối với Tomcat bất kể sử dụng tôi giấy chứng nhận - có vẻ như thất bại trong việc tra cứu hoặc một cái gì đó. Nếu tôi tạo một kết nối HTTP trên 8080 mặc dù, nó chuyển hướng tôi đến 8443. Đây là cấu hình tôi đang sử dụng. Bất kỳ ý tưởng?

tomcat-users.xml

<tomcat-users> 
<role rolename="webservice"/> 
<user username="CN=ClientCert,OU=Corp,O=Corp,L=London,S=London,C=UK" password="" roles="webservice"/> 
</tomcat-users> 

server.xml

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" 
maxThreads="150" scheme="https" secure="true" 
clientAuth="true" sslProtocol="TLS" 
keystoreFile="c:\tomcat\keys\server.jks" keystorePass="password" 
truststoreFile="c:\tomcat\keys\client.jks" truststorePass="password"/> 

web.xml

[...] 
    <security-constraint> 
     <display-name>ClientCertificateRequired</display-name> 
     <web-resource-collection> 
      <web-resource-name>MyWebService</web-resource-name> 
      <description/> 
      <url-pattern>/webservice/*</url-pattern> 
     </web-resource-collection> 
     <auth-constraint> 
      <description/> 
      <role-name>webservice</role-name> 
     </auth-constraint> 
     <user-data-constraint> 
      <description/> 
      <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
     </user-data-constraint> 
    </security-constraint> 
    <login-config> 
     <auth-method>CLIENT-CERT</auth-method> 
     <realm-name>tomcat-users</realm-name> 
    </login-config> 
    <security-role> 
     <description/> 
     <role-name>webservice</role-name> 
    </security-role> 
    [...] 
    <servlet> 
     <display-name>Webservice</display-name> 
     <servlet-name>Webservice</servlet-name> 
     <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class> 
     [...] 
      <run-as> 
      <role-name>webservice</role-name> 
     </run-as> 
    </servlet> 
    [...] 

Trả lời

2

Chỉ cần xác định URL đầu tiên là bảo đảm và yêu cầu cả hai bí mật và một cụ thể và xác định ứng dụng web bằng cách sử dụng xác thực ứng dụng khách SSL. Xác định URL thứ hai là không yêu cầu vai trò. Đây là tất cả trong web.XML. Sau đó, xác định cho mình một lĩnh vực thích hợp để kiểm tra danh tính và nhận vai trò từ đó.

+0

Cảm ơn EJP, tôi đã thử giải pháp của bạn nhưng bây giờ tôi không thể kết nối với Tomcat nữa (không quan trọng nếu tôi sử dụng chứng chỉ hay không). Tôi đã đăng các nỗ lực của mình ở trên - bạn có thể phát hiện lỗi không? – EddyYosso

4

Bạn có thể định cấu hình Tomcat để sử dụng thương lượng lại chứng chỉ ứng dụng khách (trái với thương lượng ban đầu), để việc yêu cầu chứng chỉ ứng dụng khách có phụ thuộc vào URL được yêu cầu hay không.

Để thực hiện việc này, bạn cần sử dụng clientAuth="false" trong cấu hình trình kết nối và sau đó <auth-method>CLIENT-CERT</auth-method> trong ứng dụng web bạn muốn bảo vệ bằng chứng chỉ ứng dụng khách.

Lưu ý rằng điều này sử dụng thương lượng lại và do đó bạn có thể phải đối phó với các vấn đề về lỗi thương lượng lại TLS. Trong ngắn hạn, đã có một lỗ hổng giao thức TLS được công bố vào khoảng tháng 11 năm 2009. Bản sửa lỗi bảo mật ngay lập tức là vô hiệu hóa việc thương lượng lại (trừ khi buộc tùy chọn không an toàn) và sau đó thực hiện RFC 5746. Xem các bản sửa lỗi giai đoạn 1 và giai đoạn 2 trong Oracle Java Transport Layer Security (TLS) Renegotiation Issue Readme.

Đối với những gì bạn đang cố gắng làm, bạn cần phải thương lượng lại để được bật và để đảm bảo an toàn, bạn phải sử dụng bản phát hành JRE 1.6.0_22.

Các vấn đề liên quan