Änderungen an Jboss web.xml haben keinen Einfluss

StackOverflow https://stackoverflow.com/questions/2382380

Frage

Ich habe dies gerade zu meinem web.xml auf meinem JBoss -Server hinzugefügt. Aber es hatte keine Wirkung. Ich darf immer noch eine Verbindung zu Ports herstellen, die keinen bidirektionalen Zertifikataustausch verwenden. Hat jemand eine Ideen?

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

Aktualisieren

Eigentlich scheint es, dass ich in meinem ursprünglichen Beitrag einen Fehler gemacht habe.

In der Web.xml können Benutzer mithilfe von HTTP (Port C unten) eine Verbindung zum WebService herstellen. Benutzer dürfen jedoch immer noch eine Verbindung zu Ports herstellen, die Benutzer nicht zwingen, sich selbst zu authentifizieren (Port B). Ich denke, dass Benutzer in der Lage sein sollten, eine Verbindung zum Port A herzustellen (es hat clientAuth="true") Aber ich glaube nicht, dass die Leute in der Lage sein sollten, eine Verbindung zu Port B zu verbinden (es hat clientAuth="false").

Auszug von 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>" ...
     />
War es hilfreich?

Lösung

Ich nehme den Port an <C> ist HTTP und da Sie konfiguriert haben <transport-guarantee> CONFIDENTIAL </transport-guarantee> daher Port <C> ist blockiert.

Hafen <B> verwendet SSL, was erfüllt <transport-guarantee> CONFIDENTIAL </transport-guarantee> Daher ist es nicht blockiert.

.

In Ihrer Web.xml -Konfiguration fehlen einige Elemente. Sie haben keine Autorisierungsbeschränkungen für Ihre Webressourcen. Daher, wenn Sie vom Port zugreifen <B> Auch wenn Sie nicht authnetisch sind, sind Sie dennoch befugt, auf die Ressourcen zuzugreifen, da Sie Ihre Ressourcen nicht auf Authstraationen gesetzt haben.

Sie müssen eine Liste von haben <security-role> enthält <role-name> Das kann auf diese Anwendung zugreifen.

<security-constraint> zum <web-resource-collection> sollte haben <auth-constraint> Erzählen Sie welche <role-name> Zugang zu und andere werden eingeschränkt.

Die oben konfigurierten Rollen sind Java EE -Rollen. Der Container (JBoss) muss so konfiguriert werden, dass authentifizierte Rollen den Java -EE -Rollen abbilden.

Bezug:

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

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

.

Aktualisierte Kopie der obigen 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>

.

In der Sicherheit gibt es zwei Dinge: Authentifizierung und Autorisierung.

Authentifizierung: das Gesetz der Überprüfung, ob ein Benutzer ein Thema ist und dem Benutzer bestimmte Prinzipien gewährt; "Wer du bist."

Genehmigung: Die Überprüfung der Überprüfung, ob ein Benutzer auf eine bestimmte Ressource zugreifen darf; "Was können Sie tun."

<auth-method> Sagen Sie, wie Sie einen Benutzer authentifizieren oder wie Sie fragen, wer Sie sind. Wenn der Benutzer kein Client -Zertifikat hat, ist er nicht authentifizierter Benutzer. Es zeigt nicht, was der Benutzer tun kann.

Jedoch <auth-constraint> ist was Sie tun können. Wenn Sie setzen <auth-constraint>, und dann können nur Rollen, die dort erwähnt werden, auf die jeweilige Webressource zugreifen. Sie könnten immer noch Benutzer haben, der nicht authentifiziert ist, aber befugt ist, auf bestimmte Ressourcen zuzugreifen, wenn Ressourcen nicht auf eine Zertifikatrollen beschränkt sind.

Andere Tipps

Haben Sie Ihre Webanwendung neu geladen, seit Sie Ihre Änderungen vorgenommen haben?

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top