Los cambios en JBoss Web.xml no tienen efecto

Question

Acabo de agregar esto a mi web.xml en mi servidor JBoss. Pero no tuvo efecto. Todavía se me permite conectarme a puertos que no usan intercambio de certificados bidireccionales. ¿Alguien tiene ideas?

<!-- 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>

---

Actualizar

En realidad, parece que he cometido un error en mi publicación original.

Web.xml impide que los usuarios se conecten al servicio web utilizando HTTP (puerto C a continuación). Sin embargo, los usuarios aún pueden conectarse a puertos que no obligan a los usuarios a autenticarse (puerto B). Creo que los usuarios deberían poder conectarse al puerto A (tiene clientAuth="true") pero no creo que las personas puedan conectarse al puerto B (tiene clientAuth="false").

Extracto 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>" ...
     />

Answer 1

Supongo puerto <C> es http y dado que ha configurado <transport-guarantee> CONFIDENTIAL </transport-guarantee> de ahí el puerto <C> está bloqueado.

Puerto <B> utiliza SSL que satisface <transport-guarantee> CONFIDENTIAL </transport-guarantee> Por lo tanto, no está bloqueado.

.

Le faltan pocos elementos en su configuración web.xml. No tiene restricciones de autorización en sus recursos web. Por lo tanto, cuando accede desde el puerto <B> A pesar de que no está autnetetado, todavía está autorizado para acceder a los recursos, ya que no ha puesto ninguna restricción de autores en sus recursos.

Necesitas tener una lista de <security-role> que contiene <role-name> que puede acceder a esta aplicación.

<security-constraint> por <web-resource-collection> debería tener <auth-constraint> diciendo que <role-name> para dar acceso a y otros estarán restringidos.

Los roles configurados anteriormente son los roles Java EE. El contenedor (JBOSS) debe configurarse para asignar roles autenticados a los roles Java EE.

Referencia:

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

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

.

Copia actualizada de Web.xml anterior

<!-- 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 seguridad hay dos cosas, autenticación y autorización.

Autenticación: el acto de verificar que un usuario es un tema y otorga al usuario ciertos principales; "quien eres."

Autorización: el acto de verificar que un usuario puede acceder a un cierto recurso; "Lo que puedes hacer".

<auth-method> Diga cómo autenticar a un usuario o cómo preguntar quién es usted. Si el usuario no tiene un certificado de cliente, es un usuario no autenticado. No dice qué puede hacer el usuario.

Sin embargo <auth-constraint> es lo que puedes hacer. Si pones <auth-constraint>, entonces, solo los roles mencionados allí pueden acceder al recurso web respectivo. Todavía podría tener un usuario que no esté autenticado pero que esté autorizado para acceder a ciertos recursos si los recursos no están limitados a los roles certianos.

Answer 2

¿Ha vuelto a cargar su aplicación web desde que realizó sus cambios?