JDBCRealm поддерживает CLIENT-CERT
Да, это возможно. Однако есть несколько причуд, на которые стоит обратить внимание.
Имена пользователей
Столбец имени пользователя должен содержать различающееся имя субъекта сертификата в виде строки символов. К сожалению, метод, который Tomcat использует для получения этой строки, приводит к результату, зависящему от реализации, поэтому возможно, что если вы переключитесь на нового поставщика безопасности или даже просто обновите среду выполнения Java, вам может потребоваться сопоставить имена пользователей с новой формой , Вам нужно будет протестировать развертывание, чтобы выяснить, какой формат используется.
В частности, getName()
вызывается на Principal
, возвращаемом X509Certificate.getSubjectDN()
для получения String
, который используется в качестве имени пользователя. Если вы прочитаете документацию , вы обнаружите, что это уже не лучший подход.
Аутентификация
Самый простой способ - загрузить привязки доверия в хранилище доверия Tomcat , настроенное в файле "server.xml". При такой настройке любая цепочка клиентских сертификатов, которая является корневой в одном из ваших доверенных ЦС, будет считаться «аутентифицированной», и по праву так - аутентификация означает, что идентификационная информация известна и отличается от авторизации, которая определяет, для чего этой идентификационной информации разрешено делаем.
Авторизация
Поскольку любой человек с подписанным сертификатом будет проходить проверку подлинности, вам необходимо установить роли для защиты частных ресурсов в вашем приложении. Это делается путем установки ограничений безопасности, связанных с ролями, в вашем файле "web.xml". Затем в своей базе данных заполните таблицу «ролей», чтобы предоставить доверенным пользователям дополнительные роли.
Связь между таблицей пользователей и таблицей ролей работает точно так же, как и при авторизации на основе FORM, и ее следует использовать для предоставления соответствующих разрешений пользователям, которым вы доверяете.
Примечание к паролям
JDBCRealm
создаст новый Principal , который содержит пароль, но если ваше приложение не понижает этот Principal
до реализации, специфичной для Tomcat ( GenericPrincipal ), это свойство не будет для вас видимым, и не имеет значения, что вы поместите в этот столбец. Я рекомендую NULL
.
Другими словами, при использовании JDBCRealm
с client-auth поле пароля игнорируется. У этого GenericPrincipal
есть метод доступа к основному принципалу, но, к сожалению, Principal
из сертификата не передается; JDBCRealm
установит его на ноль; единственный полезный метод в этом сценарии мог бы быть getName()
(возвращение предметного DN - возможно некоторая нестандартная форма).
Структура и содержание таблицы
Используйте точно такую же структуру таблицы, как и для JDBCRealm на основе FORM (или DatasourceRealm). Единственная разница будет в содержании. Имя пользователя будет текстовым представлением отличительного имени субъекта, а пароль будет NULL
или какое-то фиктивное значение.