Tomcat 7 вложенность CombinedRealm, LockoutRealm и DataSourceRealm

Я пытаюсь вложить области следующим образом в Tomcat 7.0.32 (написано здесь в псевдо-XML):

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

Это, похоже, не работает - возможно ли гнездить царства в Tomcat более чем на два уровня? Я получаю предупреждение в журналах:

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

идея заключается в том, что веб-служба имеет некоторых критических пользователей, которые не должны быть заблокированы (например, как DOS) и некоторые обычные пользователи, которые могут иметь более слабые пароли, где lockoutRealm должен быть активен. Я уверен в другом. люди были в такой ситуации.

Если есть другой способ достичь этого (например, белый список для LockoutRealm), пожалуйста, дайте мне знать.

Single sign on также необходим.

Я думаю, расширение существующих LockoutRealm код со списком счетов не блокировка будет вариант, но я не настолько увлечен написанием своих владениях, я предпочел бы не добавить пользовательский код на этом уровне в Tomcat, так как это осложнит установку за другим и с каждым котяра обновление может сломаться и т. д.

Спасибо за любую помощь!

вот соответствующая часть сервера.xml моей тестовой конфигурации:

<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>
7
java realm security tomcat

2 ответов

Apache commons-digester используется для анализа файлов конфигурации, поэтому я подозреваю, что этот конкретный случай использования просто не ожидался.

котяра по org.apache.catalina.startup.RealmRuleSet.addRuleInstances кажется, сфальсифицировано только на 2 уровня глубиной для Realm конфигурации. Кажется, достаточно просто добавить еще один слой.

мне нужно посмотреть, как можно настроить дигестер, чтобы увидеть, могут ли поддерживаться произвольные уровни или какое-то подмножество должно быть настроено вручную.

Не стесняйтесь направляйтесь к список пользователей Tomcat запросить такое изменение.

3

новый ответ выглядит так:

обновление до Tomcat 7.0.33 или более поздней версии. тогда он работает отлично.

Кристофер Шульц был так дружелюбен, чтобы переслать мой вопрос сюда в список пользователей Tomcat. Великие разработчики Tomcat сразу же решили эту проблему и поместили ее в следующий выпуск. Большое спасибо!

таким образом, теперь вы можете использовать конструкцию, подобную той, что в вопросе, или как это с другим порядком / "приоритеты":

...

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

...

конечно, вы также можете использовать другие области и другие комбинации.

обратите внимание, что одна вещь может вводить в заблуждение в журналах: в этой конструкции, если неправильный пароль задан для одного из критических пользователей, хранящихся в первичной области, первичная область запрещает доступ, то вторичная область через область блокировки пробуется, а также запрещает доступ в конечном итоге блокирует имя пользователя. Это регистрируется областью блокировки как предупреждение " попытка была сделано для аутентификации заблокированного пользователя ...". Все еще с правильным паролем, доступ продолжает работать через первичную область, так как он не проходит через область блокировки. Т. е. все работает по назначению, просто сообщение журнала может привести к путанице (конечно, этого нельзя избежать).

3