Изменения в JBoss web.xml не имеют никакого эффекта - PullRequest
Новая
       35

Изменения в JBoss web.xml не имеют никакого эффекта

5 голосов
/ 04 марта 2010

Я только что добавил это в мой web.xml на моем сервере JBOSS.Но это не имело никакого эффекта.Мне все еще разрешено подключаться к портам, которые не используют двунаправленный обмен сертификатами.У кого-нибудь есть идеи? 

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

Обновление

На самом деле кажется, что я допустил ошибку в моей первоначальной публикации.

Файл web.xml блокирует подключение пользователей к веб-сервису по протоколу http (порт C ниже).Однако пользователям по-прежнему разрешается подключаться к портам, которые не заставляют пользователей проходить аутентификацию (порт B).Я думаю, что пользователи должны иметь возможность подключиться к порту A (он имеет clientAuth="true"), но я не думаю, что люди должны иметь возможность подключиться к порту B (он имеет clientAuth="false").

Выдержка из 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>" ...
     />

Ответы [ 2 ]

1 голос
/ 10 марта 2010

Я предполагаю, что порт <C> является HTTP, и поскольку вы настроили <transport-guarantee> CONFIDENTIAL </transport-guarantee>, следовательно, порт <C> заблокирован.

Порт <B> использует SSL, который удовлетворяет <transport-guarantee> CONFIDENTIAL </transport-guarantee>, следовательно, он не заблокирован.

.

Вам не хватает нескольких элементов в конфигурации web.xml. У вас нет каких-либо ограничений авторизации на ваших веб-ресурсах. Следовательно, когда вы получаете доступ из порта <B>, даже если вы не прошли аутентификацию, вы по-прежнему имеете право доступа к ресурсам, поскольку вы не налагали никаких ограничений на аутентификацию для своих ресурсов.

У вас должен быть список <security-role>, содержащий <role-name>, который может получить доступ к этому приложению.

<security-constraint> для <web-resource-collection> должен иметь <auth-constraint> с указанием, к кому <role-name> будет предоставлен доступ, а другим будет запрещено.

Роли, настроенные выше, являются ролями Java EE. Контейнер (JBoss) необходимо настроить для сопоставления аутентифицированных ролей с ролями Java EE.

Ссылка:

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

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

.

Обновленная копия вышеуказанного 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>

.

В безопасности есть две вещи, аутентификация и авторизация.

Аутентификация: акт проверки того, что пользователь является субъектом и предоставления пользователю определенных принципов; "кто ты."

Авторизация: акт проверки того, что пользователю разрешен доступ к определенному ресурсу; "что вы можете сделать."

<auth-method> расскажите, как аутентифицировать пользователя или как спросить, кто вы. Если у пользователя нет сертификата клиента, он является неаутентифицированным пользователем. Он не говорит, что может делать пользователь.

Однако <auth-constraint> - это то, что вы можете сделать. Если вы введете <auth-constraint>, то только роли, упомянутые там, могут получить доступ к соответствующему веб-ресурсу У вас все еще может быть пользователь, который не аутентифицирован, но авторизован для доступа к определенным ресурсам, если ресурсы не ограничены определенными ролями.

1 голос
/ 04 марта 2010

Перезагрузили ли вы свое веб-приложение после внесения изменений?

...