<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>Механизмы аутентификации
В этом разделе рассматриваются механизмы аутентификации клиента по цифровому сертификату и взаимной аутентификации.
Здесь рассматриваются следующие темы:
Аутентификация клиента по цифровому сертификату
При аутентификации клиента по цифровому сертификату веб-сервер аутентифицирует клиента с помощью сертификата открытого ключа клиента. Аутентификация клиента по цифровому сертификату является более безопасным методом аутентификации, чем базовая аутентификация или аутентификация на основе форм. Она использует HTTP over SSL (HTTPS), при котором сервер аутентифицирует клиента, используя сертификат открытого ключа клиента. Технология SSL обеспечивает шифрование данных, проверку подлинности сервера, целостность сообщений и, опционально, аутентификацию клиента по цифровому сертификату для соединения TCP/IP. Вы можете думать о сертификате открытого ключа как о цифровом эквиваленте паспорта. Сертификат выдаётся доверенной организацией — центром сертификации (CA) и обеспечивает идентификацию для канала-носителя.
Перед использованием аутентификации клиента по цифровому сертификату убедитесь, что у клиента есть действующий сертификат открытого ключа. Для получения дополнительной информации о создании и использовании сертификатов открытых ключей прочитайте Работа с цифровыми сертификатами.
В следующем примере показано, как объявить аутентификацию клиента по цифровому сертификату в дескрипторе развёртывания:
API безопасности Java EE предоставляет альтернативные средства для настройки аутентификации клиента по цифровому сертификату с использованием интерфейса HttpAuthenticationMechanism. Этот интерфейс определяет SPI для записи механизмов аутентификации, которые могут быть предоставлены приложением и развёрнуты с использованием CDI. Смотрите Обзор интерфейса механизма аутентификации HTTP.
Взаимная аутентификация
При взаимной аутентификации сервер и клиент аутентифицируют друг друга. Взаимная аутентификация бывает двух типов:
При использовании взаимной аутентификации на основе сертификатов выполняются следующие действия.
-
Клиент запрашивает доступ к защищённому ресурсу.
-
Веб-сервер представляет свой сертификат клиенту.
-
Клиент проверяет сертификат сервера.
-
В случае успеха клиент отправляет свой сертификат на сервер.
-
Сервер проверяет учётные данные клиента.
-
В случае успеха сервер предоставляет доступ к защищённому ресурсу, запрошенному клиентом.
На рисунке 53-1 показано, что происходит во время взаимной аутентификации на основе сертификатов.
Рис. 53-1. Взаимная аутентификация на основе сертификатов
При взаимной аутентификации на основе имени пользователя и пароля выполняются следующие действия.
-
Клиент запрашивает доступ к защищённому ресурсу.
-
Веб-сервер представляет свой сертификат клиенту.
-
Клиент проверяет сертификат сервера.
-
В случае успеха клиент отправляет своё имя пользователя и пароль на сервер.
-
Сервер проверяет учётные данные клиента
-
Если проверка прошла успешно, сервер предоставляет доступ к защищённому ресурсу, запрошенному клиентом.
На рисунке 53-2 показано, что происходит во время взаимной аутентификации на основе имени пользователя и пароля.
Рис. 53-2. Имя пользователя/взаимная аутентификация на основе пароля
Включение взаимной аутентификации по SSL
В этом разделе обсуждается настройка аутентификации на стороне клиента. Включение аутентификации на стороне сервера и на стороне клиента называется взаимной, или двусторонней аутентификацией. При аутентификации клиента по цифровому сертификату клиенты должны предоставлять сертификаты, выданные центром сертификации, который вы решили принять.
Существует как минимум два способа включить взаимную аутентификацию по SSL.
-
Предпочтительным методом является установка метода аутентификации в
web.xml(дескрипторе развёртывания приложения) наCLIENT-CERT. Это обеспечивает взаимную аутентификацию путём изменения дескриптора развёртывания данного приложения. Таким образом, аутентификация клиента по цифровому сертификату включена только для определённого ресурса, контролируемого ограничением безопасности, и проверка выполняется только тогда, когда приложение требует такой аутентификации. -
Менее часто используемый метод — установить свойство
clientAuthв областиcertificateнаtrue, если вы хотите, чтобы стек SSL требовал допустимой цепочки сертификатов от клиента, прежде чем принимать соединение. Значениеfalse(по умолчанию) не потребует цепочки сертификатов, если только клиент не запросит ресурс, защищённый ограничением безопасности, использующим аутентификациюCLIENT-CERT. Когда вы включаете аутентификацию клиента по цифровому сертификату, устанавливая для свойстваclientAuthзначениеtrue, такая аутентификация будет требоваться для всех запросов, проходящих через указанный порт SSL. Если вы включитеclientAuth, он будет включён постоянно, что может серьезно снизить производительность.
Если аутентификация клиента по цифровому сертификату включена обоими этими способами, она будет выполняться дважды.
Создание сертификата клиента для взаимной аутентификации
Если у вас есть сертификат, подписанный доверенным центром сертификации (CA), таким как Verisign, и файл GlassFish Server cacerts.jks уже содержит сертификат, проверенный этим центром сертификации, вам не нужно выполнять этот шаг , Вы должны установить свой сертификат в файл сертификата сервера GlassFish только тогда, когда ваш сертификат самоподписан.
Из каталога, в котором вы хотите создать сертификат клиента, запустите keytool, как описано здесь. Когда вы кликаете Enter, keytool предлагает вам ввести имя сервера, организационную единицу, организацию, местность, штат и код страны.
Вы должны ввести имя сервера в ответ на первое приглашение keytool, в котором запрашивается имя и фамилия. В целях тестирования это может быть localhost. Если в этом примере проверяется взаимная аутентификация, и вы получаете сообщение об ошибке выполнения, в котором говорится, что имя хоста HTTPS неверно, заново создайте клиентский сертификат, убедившись, что вы используете то же имя хоста, которое вы будете использовать при выполнении примера. Например, если имя вашего компьютера — duke, введите duke в качестве certificate CN или при запросе имени и фамилии. При доступе к приложению введите URL, указывающий на то же местоположение (например, https://duke:8181/mutualauth/hello). Это необходимо, потому что во время установления соединения SSL сервер проверяет сертификат клиента, сравнивая имя сертификата с именем хоста, с которого он приходит.
Чтобы создать хранилище ключей с именем client_keystore.jks, содержащее сертификат клиента с именем client.cer, выполните следующие действия.
-
Создайте резервную копию файла хранилища доверенных сертификатов сервера. Чтобы сделать это,
-
Перейдите в каталог, содержащий файлы хранилища ключей и доверенных сертификатов сервера, domain-dir`/config`.
-
Скопируйте
cacerts.jksвcacerts.backup.jks. -
Скопируйте
keystore.jksвkeystore.backup.jks.Не помещайте клиентские сертификаты в файл
cacerts.jks. Любой сертификат, который вы добавляете в файлcacerts, может быть доверенным корнем для любой цепочки сертификатов. После завершения экспериментов удалите экспериментальную версию файлаcacertsи замените её исходной.
-
-
Сгенерируйте клиентский сертификат. Введите следующую команду из каталога, в котором вы хотите создать сертификат клиента:
java-home\bin\keytool -genkey -alias client-alias -keyalg RSA -keypass changeit -storepass changeit -keystore client_keystore.jks -
Экспортируйте сгенерированный сертификат клиента в файл
client.cer:java-home\bin\keytool -export -alias client-alias -storepass changeit -file client.cer -keystore client_keystore.jks -
Добавьте сертификат в файл хранилища доверенных сертификатов domain-dir`/config/cacerts.jks`. Запустите
keytoolиз каталога, в котором вы создали хранилище ключей и сертификат клиента. Используйте следующие параметры:java-home\bin\keytool -import -v -trustcacerts -alias client-alias -file client.cer -keystore domain-dir/config/cacerts.jks -keypass changeit -storepass changeitУтилита
keytoolвозвращает сообщение, подобное следующему:Owner: CN=localhost, OU=My Company, O=Software, L=Santa Clara, ST=CA, C=US Issuer: CN=localhost, OU=My Company, O=Software, L=Santa Clara, ST=CA, C=US Serial number: 3e39e66a Valid from: Tue Nov 27 12:22:47 EST 2012 until: Mon Feb 25 12:22:47 EST 2013 Certificate fingerprints: MD5: 5A:B0:4C:88:4E:F8:EF:E9:E5:8B:53:BD:D0:AA:8E:5A SHA1:90:00:36:5B:E0:A7:A2:BD:67:DB:EA:37:B9:61:3E:26:B3:89:46:32 Signature algorithm name: SHA1withRSA Version: 3 Trust this certificate? [no]: yes Certificate was added to keystore [Storing cacerts.jks] -
Перезагрузите сервер GlassFish.
