À l'aide de CLIENT-CERT pour Tomcat sans spécifier de nom d'utilisateur

Je suis en train de faire un applications web Tomcat utiliser l'authentification par certificat client pour les connexions entrantes. Tout fonctionne bien lors de l'utilisation de clientAuth=true dans server.xml toutefois, en raison à d'autres applications fonctionnant sur le même serveur, nous ne pouvons pas l'utiliser dans l'environnement de production.

Est-il un moyen pour former un web.xml document tel qu'il oblige le client l'utilisation de certificats pour l'application de la même manière que clientAuth=true? Il semble que l'utilisation du CLIENT-CERT paramètre exige la configuration de tomcat compte d'utilisateur pour chaque certificat qui est de l'accès à votre système? Nous devons être en mesure de permettre à tous les certificats de CA (défini dans le serveur truststore) où le sujet correspond à certaines règles (vérifié à l'intérieur de l'application elle-même). J'espérais que quelque chose comme cela pourrait fonctionner, mais pas de chance encore!

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Everything</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>
<login-config>
    <auth-method>CLIENT-CERT</auth-method>
</login-config>

OriginalL'auteur user unknown | 2012-08-01

  1. 4

    Tout d'abord, il semble que vous voulez clientAuth=want au lieu de clientAuth=true: qui permettra au client de fournir un certificat, mais pas absolument besoin d'une.

    Lorsque vous utilisez l'authentification de toute nature, Tomcat (ou tout conteneur de servlet) doit être en mesure de construire une Principal objet en dehors d'elle, qui a un nom (généralement un nom d'utilisateur). Le récipient doit décider quel est le rôle de l'utilisateur afin de bien autoriser une demande particulière. Donc, Tomcat devez savoir sur les utilisateurs à l'avance afin de faire d'autorisation de travail.

    D'autre part, si vous n'avez pas besoin d'autorisation, vous pouvez définir clientAuth=want et ensuite utiliser un Filter pour vérifier le certificat. Il n'y a pas besoin d'utiliser CLIENT-CERT d'authentification si vous faites déjà de votre propre contrôle.

    clientAuth=false dans le connecteur de config et CLIENT-CERT dans web.xml vous permet d'obtenir le certificat client pour la re-négociation, ce qui est pratique si vous ne voulez pas ou besoin, d'autres webapps à cause d'une invite dans le navigateur.
    C'est ce que j'essayais de faire ci-dessus, mais il semble que j'ai peut-être mal compris l'utilisation de la CLIENT-CERT option ici. Donc, CLIENT-CERT dans le web.xml est seulement pour l'utilisation d'un cert afin de s'authentifier en tant qu'utilisateur particulier? La plupart de mon expérience jusqu'à maintenant est avec IIS, et j'espérais Tomcat travaillé de la même façon, où vous pouvez spécifier si l'ensemble du serveur, ou un projet en particulier ou même d'une page individuelle besoin d'un certificat client valide pour être présentée avant que la connexion n'est autorisée.
    J'avais essayé clientAuth=voulez, qui a fait un travail mais je n'étais pas sûr si c'était aussi sécurisé. Cependant, le fait de réfléchir un peu plus - si aucun certificat n'est présentée, notre code du travail que de toute façon et de les rejeter. S'ils présentent un certificat client, il sera sans doute avoir à passer par la vérification que le serveur Tomcat le feriez lors de la clientAuth=true (par exemple, autorité de certification de confiance, de la validité et de la portée, etc.) avant d'être transmis à notre code pour une validation plus poussée afin qu'il fonctionne exactement de la même manière?
    Si votre application nécessite CLIENT-CERT d'authentification, puis de la webapp lui-même demande un certificat pour accéder à des ressources protégées. Le clientAuth=want empêche l' <Connector> de demander un certificat pour tous demandes. Si vous activez Tomcat, certificat de validation, la validation sera effectué si le certificat est présent, mais ignorée si elle n'est pas présente. Je pense que vous serez très bien avec la configuration que j'ai présenté.
    J'ai oublié de mentionner: pour faire confiance à tous les certificats signés par une autorité de certification, vous n'aurez qu'à configurer votre truststore correctement.

    OriginalL'auteur Christopher Schultz

  2. 2

    J'étais juste observer solution au problème ci-dessus et a finalement trouvé une solution:

    1. Configurer tomcat avec connecteur clientAuth="false" attribut(Sinon, toutes les connexions sécurisées vers le serveur fera mutuelle, client serveur, ssl authentification.

    2. Ajouter ce qui suit dans web.xml(j'ai juste montré ici exemple) 

      <security-constraint>
    <web-resource-collection>
        <url-pattern>/LoginTestServlet1</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>manager</role-name>
    </auth-constraint>
    <user-data-constraint>
        <!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE -->
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>
 <security-constraint>
    <web-resource-collection>
        <url-pattern>/LoginTestServlet2</url-pattern>
        <http-method>GET</http-method>
        <http-method>POST</http-method>
    </web-resource-collection>
    <auth-constraint>
        <role-name>manager</role-name>
    </auth-constraint>
   <!--  <user-data-constraint>
        transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>  
    </user-data-constraint> -->
</security-constraint>
 <login-config>
    <auth-method>CLIENT-CERT</auth-method>
    <realm-name>certificate</realm-name>
  </login-config>

      le gestionnaire de

    3. Dans tomcat users-users.xml ajoutez le code suivant(pls noter que si la confiance magasin a presque identique certificats ensuite, vous devez identifier clairement votre certificat comme suit) 

      <role rolename="manager"/>

      < user username="[email protected], CN=KS, unité d'organisation=NON, O=OFS, L=Boukhara,

      ST=Boukhara, C=UZ" password="" roles="manager"/>

    4. mettre dans un navigateur(ou boucle) ligne d'adresse:

      https://yourdomain.com:8443/LoginTest/LoginTestServlet1 ou

      https://yourdomain.com:8443/LoginTest/LoginTestServlet2

    5. Pour que cela fonctionne, vous devez ajouter le certificat de navigateur certificat personnel de la liste(si vous testez avec le navigateur). J'ai essayé avec Mozilla Firefox et il sera plus simple pour vous permettre de faire cela.(Mais il n'accepte b12 certificat de sorte qu'il est suggéré que vous devriez utiliser openssl avec java keytool). Si tout est configuré à droite, puis vous obtenez l'invite de mozilla pour choisir un certificat de celles déjà existantes. Si vous êtes à l'aide de curl(il est utilisé pour le web automatique des interfaces de test puis utilisez la commande suivante commant ligne pour tester(j'ai juste donné un exemple ici). Veuillez noter que vous devez choisir un certificat sur lequel vous avez importé dans le magasin de confiance.

      curl-s -k-cert autosignés.pem --key.pem -v --anyauth https://yourdomain.com:8443/LoginTest/LoginTestServlet1 --cacert autosignés.pem ou
      curl-s -k-cert autosignés.pem --key.pem -v --anyauth http://yourdomain.com:8080/LoginTest/LoginTestServlet2 --cacert autosignés.pem

    Note: Mon connecteur ressemble comme suit:

    <Connector port="8443"
       maxThreads="150"  scheme="https" secure="true" SSLEnabled="true"
       sslProtocol="TLS" keystoreType="PKCS12"  truststoreType="PKCS12" clientAuth="false"
               keystoreFile="C:/Program Files/glassfish-3.1.2/glassfish/domains/domain1/config/cacerts.pkcs12"
               truststoreFile= "C:/Program Files/glassfish-3.1.2/glassfish/domains/domain1/config/cacerts.pkcs12"
               truststorePass="changeit"
               keystorePass="changeit"
               protocol="org.apache.coyote.http11.Http11Protocol">
    J'ai testé cela sur tomcat 6.0.35 mais il faut travailler avec glassfish trop avec quelques changements de glassfish-web.xml fichier
    <security-role-mapping> <role-name>gestionnaire de</role-name> <principal-name>[email protected], CN=KS,unité d'organisation=NON,O=OFS,L=Boukhara,S=Boukhara,C=UZ</principal-name> <group-name>gestionnaire de</group-name> </security-role-mapping>
    certains certificats sont faciles à ajouter au navigateur de magasin personnel comme les certificats pkcs12. Pour les ajouter au magasin de certificats personnels de Crome/Cromium et les navigateurs Internet Explorer(nouvelles versions), double-cliquez simplement sur eux et suivez les étapes de l'assistant. Pour d'autres, comme Mozilla Firefox v 21 vous devez le faire à la main sur navigateur.
    Le cas avec l'Opéra est le même que Mozilla en ce qui concerne l'ajout de certificats pour l'authentification du certificat client
    Tous les navigateurs prennent en charge plusieurs certificats

    OriginalL'auteur Khurshed Salimov