Konfigurieren der HTTPS-Zertifikatsverwendung basierend auf der URL in Tomcat

Question

Ich entwickle eine Webanwendung, die Clientzertifikate verwendet, um sich bei Webserviceanrufen mit Jersey bei Tomcat zu authentifizieren. Das funktioniert bisher großartig, aber ich brauche ein Web-Frontend im selben Kontext, mit dem ich diese Anwendung verwalten kann. Da die SSL-Konfiguration "per Kontext" ist, scheint die einzige Option, dass das Frontend https verwendet, ein Client-Zertifikat in dem zugreifenden Browser zu installieren, der auch im Tomcat-Truststore aufgeführt ist (entweder oder die Verwendung von https insgesamt zu verwerfen). .

Um zu zeigen, was ich wirklich will:

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

die irgendwie in der Tomcat-Konfiguration, oder auch in dem Anwendungscode erreicht werden kann?

aktualisiert

habe ich versucht, die von EJP vorgeschlagene Konfiguration, aber jetzt kann ich nicht unabhängig von meiner Verwendung von Zertifikaten zu Tomcat verbinden - es während des Look-up oder etwas zu versagen scheint. Wenn ich jedoch einen HTTP-Connector auf 8080 erstelle, wird er auf 8443 umgeleitet. Dies ist die Konfiguration, die ich verwende. Irgendwelche Ideen?

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> 
    [...] 

Answer 1

nur die erste URL als gesichert definieren und sowohl Vertraulichkeit und erfordern eine spezielle Rolle und definieren Sie die Webanwendung als SSL-Clientauthentifizierung. Definieren Sie die zweite URL als keine Rolle erforderlich. Das ist alles in web.XML. Definieren Sie sich dann einen geeigneten Bereich, um Identitäten zu prüfen und Rollen von ihnen zu erhalten.

Answer 2

können Sie konfigurieren Tomcat-Client-Zertifikat Neuverhandlung zu verwenden (im Gegensatz zu anfänglichen Verhandlung gegen), so dass, ob-oder-nicht zu fragen, für ein Client-Zertifikat auf die angeforderte URL abhängt.

Um dies zu tun, müssen Sie clientAuth="false" in der Connector-Konfiguration und dann <auth-method>CLIENT-CERT</auth-method> in der Webanwendung, die Sie mit einem Client-Zertifikat schützen möchten.

Beachten Sie, dass dies die Neuverhandlung verwendet und Sie daher möglicherweise mit den Problemen bei der Neuverhandlung von TLS umgehen müssen. Kurz gesagt, es gab einen TLS-Protokollfehler, der im November 2009 veröffentlicht wurde. Der sofortige Sicherheitsfix bestand darin, die Neuverhandlung zu deaktivieren (außer die nicht sichere Option zu erzwingen) und dann die Implementierung von RFC 5746. Siehe Korrekturen für Phase 1 und Phase 2 Oracle Java Transport Layer Security (TLS) Renegotiation Issue Readme.

Für das, was Sie zu tun versuchen, müssen Sie Neuverhandlung aktiviert werden, und für diese sicher sein, dann würden Sie die JRE 1.6.0_22 Release verwenden.