Tomcat 7 nidificazione CombinedRealm, LockoutRealm e DataSourceRealm

Question

Sto cercando di Realms nido come segue Tomcat 7.0.32 (scritto qui in pseudo-XML):

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

Questo non sembra funzionare - è è possibile annidare Realms in Tomcat di più di due livelli? Ho ricevuto un avviso nei registri:

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

L'idea alla base è che il servizio web ha alcuni utenti critici che non deve essere bloccato (ad esempio, come DOS) e alcuni utenti normali, che possono avere le password deboli, dove il lockoutRealm dovrebbe essere attivo. Sono sicuro che altre persone sono state in questa situazione.

Se esiste un altro modo per ottenere questo risultato (ad esempio una lista bianca per il LockoutRealm), faccelo sapere.

È necessario anche l'accesso singolo.

Immagino che estendere il codice LockoutRealm esistente con un elenco di account da non bloccare mai sarebbe un'opzione, ma non sono così entusiasta di scrivere il mio Realm, preferirei non aggiungere codice personalizzato a quel livello a Tomcat , in quanto ciò complicherà la configurazione per gli altri e con ogni aggiornamento Tomcat potrebbe rompersi ecc.

Grazie per qualsiasi aiuto!

Ecco la parte rilevante del server.xml della mia configurazione di prova:

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

Answer 1

La nuova risposta è ora:

Update per Tomcat 7.0.33 o successivo. Quindi funziona perfettamente.

Christopher Schultz è stato così gentile da inoltrare la mia domanda qui alla lista utenti Tomcat. I grandi sviluppatori di Tomcat hanno immediatamente risolto il problema e lo inseriscono nella prossima versione. Molte grazie!

Così ora è possibile utilizzare una struttura simile a quella della domanda o come questa, con ordine diverso/"priorità":

... 

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

... 

Naturalmente si possono utilizzare anche altri regni e altre combinazioni.

Si noti che una cosa può essere fuorviante nei registri: in questa struttura, se viene fornita una password errata per uno degli utenti critici memorizzati nel dominio principale, il dominio principale nega l'accesso, quindi il dominio secondario tramite il blocco il regno viene provato e nega anche l'accesso, eventualmente bloccando il nome utente.Questo è registrato dal reame di blocco come avviso "È stato effettuato un tentativo di autenticare l'utente bloccato ...". Sempre con la password corretta, l'accesso continua a funzionare tramite il dominio principale, poiché non passa attraverso il dominio di blocco. Cioè tutto funziona come previsto, solo il messaggio di registro potrebbe portare a confusione (ovviamente questo è impossibile da evitare).

Answer 2

Apache commons-digestore viene utilizzato per analizzare i file di configurazione, così ho il sospetto questo particolare caso d'uso semplicemente non era previsto.

Tomcat's org.apache.catalina.startup.RealmRuleSet.addRuleInstances sembra attrezzato per andare solo 2 livelli in profondità per la configurazione Realm. Sembra abbastanza semplice da aggiungere un altro strato.

Dovrei esaminare come è possibile configurare il digestore per verificare se i livelli arbitrari possono essere supportati o se alcuni sottoinsiemi devono essere configurati manualmente.

Sentitevi liberi di andare al Tomcat users' list per richiedere una tale modifica.