2012-11-07 7 views
7

ich zu nisten Realms versucht wie in Tomcat 7.0.32 folgt (geschrieben hier in pseudo-XML):Tomcat 7 Verschachtelung CombinedRealm, LockoutRealm und DataSourceRealm

<CombinedRealm> 
    <LockoutRealm> 
    <DataSourceRealm/> 
    </LockoutRealm> 
    <UserDatabaseRealm/> 
</CombinedRealm> 

Dies gilt nicht zu funktionieren scheint - ist es möglich, Realms in Tomcat um mehr als zwei Ebenen zu verschachteln? Ich erhalte eine Warnung in den Protokollen:

No rules found matching 'Server/Service/Engine/Realm/Realm/Realm'. 

Die Idee dahinter ist, dass der Web-Service einige kritische Benutzern, die nicht gesperrt (zB als DOS) werden müssen, und einige normale Benutzer, die schwächer Passwörter haben, wo der LockoutRealm aktiv sein sollte. Ich bin sicher, dass andere Leute in dieser Situation waren.

Wenn es eine andere Möglichkeit gibt, dies zu erreichen (z. B. eine Whitelist für den LockoutRealm), lassen Sie es mich bitte wissen.

Einmaliges Anmelden wird ebenfalls benötigt.

Ich denke, das Erweitern des vorhandenen LockoutRealm-Codes mit einer Liste von Konten, die nie gesperrt werden, wäre eine Option, aber ich bin nicht so scharf darauf, meinen eigenen Realm zu schreiben. Ich würde Tomcat lieber keinen benutzerdefinierten Code auf dieser Ebene hinzufügen , da dies das Setup für andere verkompliziert und mit jedem Tomcat-Update könnte es brechen usw.

Vielen Dank für jede Hilfe!

Hier ist der relevante Teil der server.xml meines Test config:

<Engine name="Catalina" defaultHost="localhost"> 

    <Realm className="org.apache.catalina.realm.CombinedRealm"> 

    <!-- Lockout realm for the DB users --> 
    <Realm className="org.apache.catalina.realm.LockOutRealm"> 
     <!-- PRIMARY: DataSourceRealm with user DB --> 
     <Realm className="org.apache.catalina.realm.DataSourceRealm" 
     dataSourceName="jdbc/authority" 
     userTable="user" userNameCol="username" 
     userCredCol="password" digest="SHA" 
     userRoleTable="user_role" roleNameCol="rolename" /> 
    </Realm> 

    <!-- FALLBACK: 
     This Realm uses the UserDatabase configured in the global JNDI 
     resources under the key "UserDatabase". Any edits 
     that are performed against this UserDatabase are immediately 
     available for use by the Realm. --> 
    <Realm className="org.apache.catalina.realm.UserDatabaseRealm" 
      resourceName="UserDatabase"/> 

    </Realm> 

    <Host name="localhost" appBase="webapps" 
     unpackWARs="true" autoDeploy="true"> 

    <!-- SingleSignOn valve, share authentication between web applications 
     Documentation at: /docs/config/valve.html --> 
    <Valve className="org.apache.catalina.authenticator.SingleSignOn" /> 

    <!-- Access log processes all example. 
     Documentation at: /docs/config/valve.html 
     Note: The pattern used is equivalent to using pattern="common" --> 
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" 
      prefix="localhost_access_log." suffix=".txt" 
      pattern="%h %l %u %t &quot;%r&quot; %s %b" /> 

    </Host> 
</Engine> 

Antwort

3

Die neue Antwort lautet jetzt:

Update auf Tomcat 7.0.33 oder höher. Dann funktioniert es perfekt.

Christopher Schultz war so freundlich, meine Frage hier an die Tomcat-Benutzerliste weiterzuleiten. Die großen Tomcat-Entwickler haben das Thema sofort angesprochen und in die nächste Version gebracht. Danke vielmals!

So können Sie nun eine Konstruktion wie die in der Frage und wie diese mit anderer Reihenfolge/„Prioritäten“ verwenden:

... 

<Engine name="Catalina" defaultHost="localhost"> 

    <Realm className="org.apache.catalina.realm.CombinedRealm"> 

    <!-- PRIMARY: tomcat-users.xml with critical system users 
        that should always work, DB independent and without lockout 
        NOTE: If the wrong password is given, the secondary path with 
         lockout is still attempted, so that a lockout on that path 
         will still occur and be logged. Still the primary path is not 
         locked for access by that happening.       --> 
    <Realm className="org.apache.catalina.realm.UserDatabaseRealm" 
      resourceName="UserDatabase"/> 

    <!-- SECONDARY: DataSourceRealm with DB with lockout functionality --> 
    <!-- (three level nesting of realms requires Tomcat >= 7.0.33)  --> 
    <Realm className="org.apache.catalina.realm.LockOutRealm" 
     failureCount="5" lockOutTime="60" > <!-- note that when an account is locked correct password 
               login is no longer possible (would otherwise defeat purpose of lockout), 
               but also lockoutTime is still reset in each correct attempt --> 

     <Realm className="org.apache.catalina.realm.DataSourceRealm" 
     dataSourceName="jdbc/authority" 
     userTable="user" userNameCol="username" 
     userCredCol="password" digest="SHA" 
     userRoleTable="user_role" roleNameCol="rolename" /> 

    </Realm> 

    </Realm> 

    <Host > 

    ... 

    </Host> 
</Engine> 

... 

Natürlich können Sie auch zum Einsatz andere Realms und andere Kombinationen.

Beachten Sie, dass eine Sache in den Protokollen irreführend sein kann: Wenn für einen der im primären Bereich gespeicherten kritischen Benutzer ein falsches Kennwort vergeben wird, verweigert der primäre Bereich den Zugriff, dann der sekundäre Bereich über die Sperre Realm wird ausprobiert und verweigert den Zugriff, um den Benutzernamen zu sperren.Dies wird vom Sperrbereich als Warnung protokolliert. "Es wurde versucht, den gesperrten Benutzer zu authentifizieren ...". Immer noch mit korrektem Passwort funktioniert der Zugriff weiterhin über den primären Bereich, da er nicht über den Sperrbereich läuft. I.e. alles funktioniert wie beabsichtigt, nur die Log-Nachricht kann zu Verwirrung führen (das ist natürlich nicht zu vermeiden).

3

Apache commons-Kocher verwendet wird, um die Konfigurationsdateien zu analysieren, so dass ich vermute, dass dieser besondere Anwendungsfall einfach war nicht zu erwarten.

Tomcat org.apache.catalina.startup.RealmRuleSet.addRuleInstances scheint manipuliert zu werden, um nur 2 Ebenen Tiefe für Realm Konfiguration zu gehen. Scheint einfach genug, um eine weitere Ebene hinzuzufügen.

Ich müsste schauen, wie der Digestor konfiguriert werden kann, um zu sehen, ob beliebige Ebenen unterstützt werden könnten, oder ob eine Untermenge manuell konfiguriert werden müsste.

Fühlen Sie sich frei, um auf die Tomcat users' list zu gehen, um eine solche Änderung anzufordern.

+0

Christopher, vielen Dank für die ausgezeichnete Antwort! Außerdem werde ich mir die Benutzerliste ansehen (es ist wahrscheinlich an der Zeit, dass ich mich dort anmelde, nur dass ich immer zu viele verschiedene Technologien verwende, um alle Benutzerlisten zu abonnieren ...). Klingt so, als würde ich nicht in der Lage sein, den Tomcat-Code zu ändern/zu erweitern, es sei denn, der offizielle Code würde in naher Zukunft beliebig verschachtelte Levels unterstützen. Wenn ich anfangen muss, den Tomcat-Code zu ändern, würde ich den LockoutRealm wahrscheinlich eher um eine Username-Ausschlussoption erweitern - oder würden Sie wissen, ob etwas Ähnliches existiert? Vielen Dank! – FelixD

+0

Ich habe einen [Fehlerbericht dafür] (https://issues.apache.org/bugzilla/show_bug.cgi?id=54141) protokolliert. –

+0

Großartig, danke Christopher! Tut mir leid, dass ich das nicht selbst gemacht habe, ein bisschen stressig hier im Moment ... – FelixD