Changes to JBoss web.xml have no effect

Question

I just added this to my web.xml on my JBOSS server. But it had no effect. I am still allowed to connect to ports that do not use bi-directional certificate exchange. Anyone have an 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/[email protected]/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>

---

Update

Actually it appears that I have made an error in my original posting.

The web.xml does block users from connecting to the webservice using http (port C below). However users are still allowed to connect to ports that do not force users to authenticate themselves (port B). I think that users should be able to connect to port A (it has clientAuth="true") but I dont think that people should be able to connect to port B (it has clientAuth="false").

Excerpt from 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

Have you reloaded your web application since you made your changes?

Answer 2

I assume port <C> is HTTP and since you have configured <transport-guarantee> CONFIDENTIAL </transport-guarantee> hence port <C> is blocked.

Port <B> does uses SSL which satisfies <transport-guarantee> CONFIDENTIAL </transport-guarantee> hence it is not blocked.

.

You are missing few elements in your web.xml configuration. You don't have any authorization constraints on your web resources. Hence when you access from port <B> even though you are not authneticated you are still authorized to access the resources as you have not put any auth-constraints on your resourses.

You need to have list of <security-role> containing <role-name> that can access this application.

<security-constraint> for <web-resource-collection> should have <auth-constraint> telling which <role-name> to give access to and others will be restricted.

The roles configured above are JEE roles. Container(JBoss) needs to be configured to map authenticated roles to JEE roles.

Reference:

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

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

.

Updated copy of above 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/[email protected]/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>

.

In security there are two things, authentication and authorization.

Authentication: the act of verifying that a user is a subject and granting the user certain principals; "who you are."

Authorization: the act of verifying that a user is allowed to access a certain resource; "what you may do."

<auth-method> tell how to authenticate a user or how to ask who you are. If user does not have client certificate, he is unauthenticated user. It does not tell what user can do.

However <auth-constraint> is what you may do. If you put <auth-constraint>, then only roles mentioned in there can access the respective web resource. You could still have user who is not authenticated but is authorized to access certain resources if resources are not constrainted to certian roles.