Question

Je viens d'ajouter cela à mon web.xml sur mon serveur JBoss. Mais cela n'a eu aucun effet. Je suis toujours autorisé à me connecter à des ports qui n'utilisent pas d'échange de certificat bidirectionnel. Quelqu'un a-t-il des idées?

<!-- Force SSL for entire site as described here: http://wiki.metawerx.net/wiki/ForcingSSLForSectionsOfYourWebsite -->
<security-constraint>

        <!-- defines resources to be protected (in this case everything)-->
        <web-resource-collection>
                <!-- name for the resource, can be anything you like -->
                <!-- Question: is this referenced anywhere else? -->
                <web-resource-name>
                        Entire Application
                </web-resource-name>

                <!-- protect the entire application -->
                <url-pattern>
                        /*
                </url-pattern>
        </web-resource-collection>



        <!-- defines protection level for protected resource -->
        <user-data-constraint>
                <!-- data cannot be observed or changed                                 -->
                <!-- how it works in tomcat:                                            -->
                <!--    if (set to integral or confidential && not using ssl)           -->
                <!--            redirect sent to client, redirecting them to same url   -->
                <!--            but using the port defined in the redirect port         -->
                <!--            attribute in the <Connector> element of server.xml      -->
                <!--            default is 443, so in other words user is redirected    -->
                <!--            to same page using ssl.                                 -->
                <!-- BUT it is differnt for JBOSS!!  See this link: http://wiki.metawerx.net/wiki/ForcingSSLForSectionsOfYourWebsite -->
                <transport-guarantee>
                        CONFIDENTIAL
                </transport-guarantee>
        </user-data-constraint>

</security-constraint>

<login-config>

        <!-- Client-side SSL certificate based authentication.  The cert is passed to the server to authenticate -->
        <!-- I am pretty sure that CLIENT-CERT should have a dash NOT an underscore see: http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg139845.html -->
        <!-- CLIENT-CERT uses a client's AND server's certificates.  See: http://monduke.com/2006/01/19/the-mysterious-client-cert/ -->
        <auth-method>
                CLIENT-CERT
        </auth-method>     
</login-config>

Mise à jour

En fait, il semble que j'ai fait une erreur dans ma publication d'origine.

Le web.xml empêche les utilisateurs de se connecter au service Web à l'aide de HTTP (port C ci-dessous). Cependant, les utilisateurs sont toujours autorisés à se connecter à des ports qui ne forcent pas les utilisateurs à s'authentifier (port B). Je pense que les utilisateurs devraient être en mesure de se connecter au port A (il a clientAuth="true") Mais je ne pense pas que les gens devraient être en mesure de se connecter au port B (il a clientAuth="false").

Extrait de server.xml

  <Connector port="<A>" ... SSLEnabled="true"
       ...
       scheme="https" secure="true" clientAuth="true"
       keystoreFile="... .keystore"
       keystorePass="pword"
       truststoreFile="... .keystore"
       truststorePass="pword"
       sslProtocol="TLS"/>

  <Connector port="<B>" ... SSLEnabled="true"
       ...
       scheme="https" secure="true" clientAuth="false"
       keystoreFile="... .keystore"
       keystorePass="pword" sslProtocol = "TLS" />


  <Connector port="<C>" ...
     />
Était-ce utile?

La solution

Je suppose que le port <C> est http et depuis que vous avez configuré <transport-guarantee> CONFIDENTIAL </transport-guarantee> D'où le port <C> est bloqué.

Port <B> utilise SSL qui satisfait <transport-guarantee> CONFIDENTIAL </transport-guarantee> Par conséquent, il n'est pas bloqué.

.

Vous manquez quelques éléments dans votre configuration web.xml. Vous n'avez aucune contrainte d'autorisation sur vos ressources Web. Par conséquent, lorsque vous accédez à partir du port <B> Même si vous n'êtes pas autorifié, vous êtes toujours autorisé à accéder aux ressources car vous n'avez pas mis les contraintes d'automobiles sur vos ressources.

Vous devez avoir une liste de <security-role> contenant <role-name> qui peut accéder à cette application.

<security-constraint> pour <web-resource-collection> avoir dû <auth-constraint> dire quel <role-name> pour donner accès à et autres seront limités.

Les rôles configurés ci-dessus sont les rôles Java EE. Le conteneur (JBoss) doit être configuré pour cartographier les rôles authentifiés aux rôles Java EE.

Référence:

http://java.sun.com/javaee/5/docs/tutorial/doc/bncbe.html

http://community.jboss.org/wiki/rolemappingloginmodule

.

Copie mise à jour de ci-dessus web.xml

<!-- Force SSL for entire site as described here: http://wiki.metawerx.net/wiki/ForcingSSLForSectionsOfYourWebsite -->
<security-constraint>

        <!-- defines resources to be protected (in this case everything)-->
        <web-resource-collection>
                <!-- name for the resource, can be anything you like -->
                <!-- Question: is this referenced anywhere else? -->
                <web-resource-name>
                        Entire Application
                </web-resource-name>

                <!-- protect the entire application -->
                <url-pattern>
                        /*
                </url-pattern>
        </web-resource-collection>

        <auth-constraint>
            <description>Authorized Roles</description>
            <role-name>ALL_AUTHENTICATED</role-name>
        </auth-constraint>


        <!-- defines protection level for protected resource -->
        <user-data-constraint>
                <!-- data cannot be observed or changed                                 -->
                <!-- how it works in tomcat:                                            -->
                <!--    if (set to integral or confidential && not using ssl)           -->
                <!--            redirect sent to client, redirecting them to same url   -->
                <!--            but using the port defined in the redirect port         -->
                <!--            attribute in the <Connector> element of server.xml      -->
                <!--            default is 443, so in other words user is redirected    -->
                <!--            to same page using ssl.                                 -->
                <!-- BUT it is differnt for JBOSS!!  See this link: http://wiki.metawerx.net/wiki/ForcingSSLForSectionsOfYourWebsite -->
                <transport-guarantee>
                        CONFIDENTIAL
                </transport-guarantee>
        </user-data-constraint>

</security-constraint>

<login-config>

        <!-- Client-side SSL certificate based authentication.  The cert is passed to the server to authenticate -->
        <!-- I am pretty sure that CLIENT-CERT should have a dash NOT an underscore see: http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg139845.html -->
        <!-- CLIENT-CERT uses a client's AND server's certificates.  See: http://monduke.com/2006/01/19/the-mysterious-client-cert/ -->
        <auth-method>
                CLIENT-CERT
        </auth-method>     
</login-config>
<security-role>
    <description>All authenticated users</description>
    <role-name>ALL_AUTHENTICATED</role-name>
</security-role>

.

En sécurité, il y a deux choses, l'authentification et l'autorisation.

Authentification: l'acte de vérifier qu'un utilisateur est un sujet et d'accorder à l'utilisateur certains directeurs; "qui tu es."

Autorisation: l'acte de vérifier qu'un utilisateur est autorisé à accéder à une certaine ressource; "Ce que vous pouvez faire."

<auth-method> Dites comment authentifier un utilisateur ou comment demander qui vous êtes. Si l'utilisateur n'a pas de certificat client, il est un utilisateur non authentifié. Il ne dit pas ce que l'utilisateur peut faire.

Cependant <auth-constraint> c'est ce que vous pouvez faire. Si vous mettez <auth-constraint>, alors seuls les rôles mentionnés dans là peuvent accéder à la ressource Web respective. Vous pourriez toujours avoir un utilisateur qui n'est pas authentifié mais qui est autorisé à accéder à certaines ressources si les ressources ne sont pas limitées aux rôles certian.

Autres conseils

Avez-vous rechargé votre application Web depuis que vous avez apporté vos modifications?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top