При использовании взаимной аутентификации на базе сертификатов происходят следующие действия.

1.Клиент запрашивает доступ к защищенному ресурсу.

2.Сервер веб представляет свой сертификат клиенту.

3.Клиент проверяет сертификат сервера.

4.Если проверка прошла успешно, клиент посылает свой сертификат серверу.

5.Сервер проверяет мандат пользователя.

6.Если проверка прошла успешно, сервер предоставляет доступ к защищенно-

му ресурсу, запрошенному клиентом.

Во взаимной аутентификации на основе имени пользователя и пароля проис-

ходят следующие действия.

1.Клиент запрашивает доступ к защищенному ресурсу.

2.Сервер веб представляет свой сертификат клиенту.

3.Клиент проверяет сертификат.

4.Если проверка прошла успешно, клиент посылает свое имя пользователя и

пароль в сервер, который проверяет мандат.

5.Если проверка имеет успех, сервер предоставляет доступ к защищенному

ресурсу, запрашиваемому клиентом.

Дайджест-аутентификация

Подобно базовой HTTP-аутентификации, дайджест-аутентификация (то есть укороченная) HTTP удостоверяет пользователя на основе имени и пароля. Тем не менее, в отличие от базовой аутентификации, дайджест не посылает пароли пользо-

вателя по сети. В дайджест-аутентификации HTTP клиент посылает односторонний

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

Следующий пример показывает как объявлять дайджест-аутентификацию

HTTP в дескрипторе развертывания:

<login-config> <auth-method>DIGEST</auth-method>

</login-config>

16.4.Использование защищенного соединения SSL

Технология Secure Socket Layer (SSL) обеспечивает безопасность в слое транс-

порта. SSL разрешает браузеру и веб-серверу связываться безопасным соединением,

в котором пересылаемые данные кодируются при передаче и декодируются при при-

еме перед обработкой. Как окно просмотра, так и сервер кодируют трафик перед посылкой любых данных. SSL обеспечивает следующие важные задачи безопасности.

•Аутентификация (Authentication): в течение начальной попытки связи с

веб-сервером по безопасному соединению, сервер обеспечит вашему веббраузеру набор мандатов в форме сертификата сервера. Цель сертификата заключается в том, чтобы проверить подлинность сайта. В некоторых случаях сервер может запросить сертификат клиента (аутентификация клиента).

202

•Конфиденциальность (Confidentiality): когда данные передаются между клиентом и сервером в сети, третья сторона может просмотреть и исказить дан-

ные. Ответы SSL кодируются, чтобы все конфиденциальные данные не могли

быть расшифрованы третьей стороной.

•Целостность (Integrity): когда данные переданы между клиентом и сервером

в сети, SSL гарантирует, что данные не будут модифицированы при передаче

третьей стороной.

16.4.1. Установка и конфигурирование поддержки SSL

Коннектор SSL HTTPS всегда доступен на сервере GlassFish. Так как есть общие

правила настройки SSL для сервера, вы должны обратить внимание на следующее:

•должен быть элемент Connector для SSL в дескрипторе развертывания сервера;

•должны быть правильные файлы keystore и сертификата;

•позиция файла keystore и пароль должны быть определены в дескрипторе

развертывания сервера.

Задание безопасного соединения в дескрипторе развертывания

Задание требования передавать защищенные ресурсы по защищенному транс-

портному уровню (SSL) производится в дескрипторе развертывания приложения.

Следующий пример дескриптора развертывания web.xml определяет, что используется SSL:

<security-constraint> <web-resource-collection>

<web-resource-name>view dept data</web-resource-name> <url-pattern>/hr/employee/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method>

</web-resource-collection> <auth-constraint>

<role-name>DEPT_ADMIN</role-name> </auth-constraint>

<user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint> </security-constraint>

Ограничение данных пользователя (<user-data-constraint> в дескрипторе развертывания) требует, чтобы все URL и методы HTTP, определённые ограничениями

безопасности, получали соединение в защищенном транспортном слое, например,

HTTPS (HTTP поверх SSL). Ограничение данных пользователя определяет гарантию транспорта (<transport-guarantee> в дескрипторе развертывания). Значения для транс-

портной гарантии включает CONFIDENTIAL, INTEGRAL или NONE. Если вы опреде-

ляете ограничение безопасности CONFIDENTIAL или INTEGRAL, то тип ограничения

безопасности относится к запросам, которые сопоставляются с URL в коллекции веб-

ресурсов, но не с диалоговым окном логина.

Сила необходимой защиты определяется значением транспортной гарантии:

•CONFIDENTIAL — приложение требует помешать кому-либо наблюдать со-

держание передачи.

•INTEGRAL — приложение требует, чтобы данные были переданы между клиентом и сервером, чтобы нельзя было их изменить при передаче.

203

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

Ограничение данных пользователя удобно для базовой аутентификации поль-

зователя и на основе формы. Когда метод аутентификации входа установлен в BASIC

или FORM, пароли не защищаются при передаче между клиентом и сервером в не-

защищенном сеансе и могут быть просмотрены и перехвачены третьими сторонами. Использование ограничения данных пользователя с механизмом аутентификации

пользователя может облегчить эту проблему.

16.4.2. Верификация поддержки SSL

Для целей тестирования, чтобы проверить, что поддержка SSL правильно уста-

новлена, загрузим страницу по умолчанию, запрашивая URL с порта, который опреде-

лен в дескрипторе развертывания сервера: https://localhost:8181/

В этом URL https указывает, что окно просмотра использует протокол SSL. В

этом примере localhost считает, что вы выполняете запрос на вашей локальной маши-

не как часть процесса разработки. В этом примере 8181 — безопасный порт, который

определяется тем, где был создан коннектор SSL.

Когда это приложение загружается впервые, на дисплее появляется диалог New Site Certificate или Security Alert. Выберите Next, перемещаясь по серии диалоговых окон, и выберите Finish, когда достигнете последнего диалогового окна. Сертификаты отображаются только один раз. Когда вы принимаете сертификаты, последующие об-

ращения к этому сайту предполагают, что вы все еще доверяете его содержимому.

Особенности исполнения SSL

Протокол SSL предназначен для достижения максимально возможной надёжности. Тем не менее, шифрование и расшифровка — в вычислительном отношении

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

все приложение веб под SSL, и разработчику нужно решить, какие страницы требуют безопасной связи и какие — нет. Например, страницы, требующие безопасной связи, включают регистрацию, персональные данные, корзину покупок или любые страницы с информацией о кредитных карточках. Любая страница в пределах приложения, для

которой может потребоваться безопасное соединение, просто задаёт адрес с исполь-

зованием префикса протокола https: вместо http:. Любые страницы, которые требуют совершенно безопасной связи, должны проверять тип протокола в запросе и выполнять подходящее действие, если https не определен.

Использование виртуальных хостов на основе имени на защищенной связи мо-

жет быть проблематичным. Это — запроектированное ограничение самого протокола

SSL. Поддержка SSL, где окно просмотра клиента принимает сертификат сервера,

должна произойти прежде, чем HTTP-запрос будет доступен. В результате информация запроса, содержащая виртуальное главное имя, не может быть определена перед

аутентификацией, и следовательно, невозможно назначить несколько сертификатов

на один IP-адрес. Если все виртуальные хосты в единственном IP-адресе нуждаются

в одинаковом сертификате, дополнительные виртуальные хосты не должны создавать помехи нормальным операциям SSL на сервере. Тем не менее, надо иметь в виду, что несколько окон просмотра клиентов сравнивают доменное имя с доменным именем, указанным в сертификате (это сделано первоначальным органом, подписавшим

сертификат). Если доменные имена не соответствуют, окна просмотра отображают

204

предупреждение клиенту. В общих чертах, только базирующиеся на адресах виртуальные хосты обычно используют SSL в среде production.

16.5. Введение в сертификаты

(Certificate) и SSL

Digital certificates — цифровые сертификаты (или просто сертификаты). Это

электронные файлы, которые однозначно идентифицируют людей и ресурсы в Интернете. Сертификаты также обеспечивают безопасную, конфиденциальную связь

между двумя объектами.

Есть разные типы сертификатов, как например, персональные сертификаты,

использованные индивидуумами, и сертификаты сервера, используемые, чтобы уста-

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

ных слоев для сокетов (Secure Sockets Layer — SSL).

Сертификаты основаны на криптографии с открытым ключом, которая использует пары цифровых ключей (очень длинные числа), чтобы кодировать информацию

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

Получатель затем декодирует информацию, чтобы ее прочитать.

Ключевая пара содержит общий и закрытый ключи. Владелец распространяет общий ключ и делает его доступным для каждого. Но владелец никогда не распространяет закрытый секретный ключ. Поскольку ключи математически связаны, данные, закодированные одним ключом, могут декодироваться только другим ключом пары.

Сертификаты выпускаются надежными центрами сертификации Certification

Authority (CA). CA аналогичен паспортному столу: он подтверждает тождество держателя сертификата и подписывает сертификат так, что он не может быть подделан или фальсифицирован. Как только CA подписал сертификат, держатель может представить его как доказательство своей личности и выполнения закодированной, кон-

фиденциальной связи.

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

Дополнительно к открытому ключу сертификат обычно включает информацию:

•имя держателя и другую идентификацию, например, URL веб-сервера, использовавшего сертификат, или личный адрес email;

•имя СА, которое выпустило этот сертификат;

•дату истечения срока.

Цифровые сертификаты определяются технической спецификацией формата

X.509. Для того чтобы проверять тождество пользователя в области сертификата, сервис аутентификации проверяет сертификат X.509, использовав общую область имени

сертификата X.509 как имя принципала.

О файлах сертификатов

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

фикатов в директории domain-dir/config:

•Файл keystore.jks содержит сертификат сервера, включая закрытый ключ. Файл keystore защищен паролем.

205

•Файл cacerts.jks содержит все надежные сертификаты, включая сертификаты клиентов. Для надежности сервер подтверждает, что открытый ключ в

сертификате принадлежит владельцу сертификата. Надёжные сертификаты

обычно создают авторитетные организации сертификации (CA).

Если необходимо, можно сгенерировать сертификат, используя утилиту keytool.

Утилита хранит ключи и сертификаты в файле с окончанием keystore, репозиторий сертификатов используется для идентификации клиента или сервера. Обычно хра-

нилище ключей является файлом, содержащим идентификацию одного клиента или

одного сервера. Файл защищен паролем. Утилита ключей генерирует пару ключей

по умолчанию в файле keystore.jks. Пара генерируется алгоритмом шифрования

RSA (акроним авторов Rivest, Shamir и Adelman), с паролем по умолчанию changeit. Утилита запускается в директории, где нужно создать ключевую пару.

Генерация сертификата сервера производится вызовом:

java-home/bin/keytool -genkey -alias server-alias -keyalg RSA -keypass changeit -storepass changeit -keystore keystore.jks

После старта утилита запрашивает имя сервера (для целей тестирования localhost), тип организации, организацию, расположение, состояние и код страны.

Экспорт сгенерированного сертификата сервера в keystore.jks в файл server.cer:

java-home/bin/keytool -export -alias server-alias -storepass changeit -file server.cer -keystore keystore.jks

Для добавления сертификата сервера в файл cacerts.jks вызвать:

java-home/bin/keytool -import -v -trustcacerts -alias server-alias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit

При работе утилиты будет показана информация о сертификате:

Owner: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara, ST=CA, C=USIssuer: CN=localhost, OU=Sun Micro, O=Docs, L=Santa Clara,

ST=CA,

C=USSerial number: 3e932169Valid from: Tue Apr 08Certificate fingerprints:MD5: 52:9F:49:68:ED:78:6F:39:87:F3:98:B3:6A:6B:0F:90

SHA1:

EE:2E:2A:A6:9E:03:9A:3A:1C:17:4A:28:5E:97:20:78:3F: Trust this certificate? [no]:

Введите yes на заданный запрос и получите сообщение:

Certificate was added to keystore[Saving cacerts.jks]

Дополнительно можно получить информацию о сертификатах командами:

keytool -list -keystore keystore.jks -alias server-alias -v keytool -list -keystore cacerts.jks

206

17. Подготовка

приложения к развертыванию

Apache Ant — это средство компоновки, основанное на Java [9]. Согласно утверждениям ее первого автора Джеймса Данкана Дэвидсона. (James Duncan Davidson), это название — акроним «another neat tool» («еще одно средство автома-

тизации»).

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

ки приложений становится все более сложным, важно гарантировать постоянство процесса при каждой компоновке с максимально возможной автоматизацией, чтобы её результаты всегда были непротиворечивы. Традиционные проекты в C или C++ часто используют для этих целей программу make, в которой задания компоновки выполняются командами оболочки, а зависимости между заданиями компоновки определяются таким образом, что они всегда выполняются в нужном порядке.

Программа Ant похожа на make в том, что она определяет зависимости между

заданиями компоновки, однако вместо реализации заданий компоновки с использова-

нием зависящих от платформы команд оболочки используются кросс-платформенные Java-классы. С помощью Ant вы можете написать файл компоновки, который работает одинаково на любой Java-платформе (поскольку Ant сама реализована в Java); в этом заключается её преимущество.

Ant не определяет свой собственный синтаксис, вместо этого его файлы ком-

поновки записываются в XML. Существует определённый набор XML-элементов, которые понимает Ant, и для расширения возможностей Ant могут быть определены новые элементы. Задание на работу Ant определяется указанием файла компоновки в командной строке при его запуске. Если имя файла компоновки не указано, то отыски-

вается файл build.xml. Каждый файл компоновки состоит из одного элемента высшего

уровня project (проект), который, в свою очередь, состоит из одного или более элементов target (цель).

target — это отдельный этап компоновки, выполняющий любое количество

операций, например, компилирование исходных файлов. Операции задаются другими

специализированными тегами task (задание). Эти задания затем группируются вместе в элементы target. Обычно работа по компоновке разбивается на логические этапы компоновки, и каждый этап помещается в свой собственный элемент target. Это позво-

ляет выполнять одну определённую часть общей компоновки без необходимости вы-

полнения других частей. Например, активируя только определённые элементы target,

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

Элемент высшего уровня project должен всегда содержать обязательный атрибут default (по умолчанию), указывающий цель, которая должна быть выполнена, если

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

цель при помощи элемента target. Ниже приведён пример пустого файла компоновки:

<?xml version="1.0"?>

<project default="init" name="Project Argon"> <description>

A simple project introducing the use of descriptive tags in Ant build files.

207

</description>

<!-- могут также использоваться XML-комментарии --> <target name="init" description="Initialize database"> <!-- здесь нужно выполнить инициализацию -->

</target>

</project>

Свойства в Ant аналогичны переменным в языках программирования в том, что

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

изменены после их установки. Свойства в Ant постоянны, как объекты String в языке Java, что поначалу может показаться ограничением, но в конце концов, это средство компоновки, а не язык программирования. Если вы попытаетесь дать существующему свойству новое значение, это не будет считаться ошибкой, но свойство сохранит свое

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

Основываясь на описательных именах элементов и атрибутов, рассмотренных ранее, мы не должны удивляться тому, что тег установки свойств в Ant выглядит сле-

дующим образом:

<property name="propName" value="propValue"/>

или в упрощенной форме:

<property propName="propValue"/>

Для обращения к этому свойству в остальных местах нашего файла компоновки можно было бы использовать следующий синтаксис:

${propName}

В Ant существует несколько предопределённых свойств. Во-первых, все системные свойства, установленные Java-средой и использующиеся для запуска Ant, доступны как Ant-свойства, например, ${user.home}. Кроме них, Ant определяет небольшой набор своих собственных свойств, включая ${ant.version} и ${basedir} — абсолютный путь каталога проекта.

Свойства часто используются для ссылки на файлы или каталоги файловой системы, но это может вызвать проблемы на различных платформах с различными символами-разделителями пути (например: «/»и «\»). Атрибут location специально

предназначен для хранения путей файловой системы независимым от платформы способом. Вы могли бы использовать location следующим образом:

<property name="database-file" location="archive/databases/${metal}.db"/>

По умолчанию при запуске Ant ищет файл с именем build.xml. Следовательно,

если ваш файл компоновки использует это имя, вам не нужно указывать его в командной строке. Когда надо исполнить файлы компоновки с другими именами, используется аргумент -buildfile <file> или его сокращенная версия -f <file>.

Другим полезным параметром является опция -D, применяемая для установки свойств, которые могут быть использованы в файле компоновки. Она применяется для предварительной настройки свойств компоновки, используемых в задании. Например,

208

для установки свойства с именем app в необходимое значение можно использовать

следующий параметр командной строки: ant -Dapp=ch1/login

Компоновка проекта обычно требует нескольких этапов: например, сначала

компиляция исходного кода, а затем пакетирование его в файлы Java Archive Files

(JAR). Многие из этих этапов имеют четко определённый порядок: например, нельзя

пакетировать файлы классов, пока они не будут сгенерированы компилятором из ис-

ходного кода. Вместо указания целей в порядке следования Ant использует более гиб-

кий подход определения зависимостей, аналогично программе make и другим сред-

ствам компоновки. Каждая цель определяется в терминах всех других целей, которые

должны быть завершены перед ее выполнением. Это реализуется при помощи атри-

бута depends элемента target. Например:

<target name="init"/>

<target name="preprocess" depends="init"/> <target name="compile" depends="init,preprocess"/> <target name="package" depends="compile"/>

Такой подход позволяет указать компоновку любого этапа проекта; Ant предварительно обеспечит выполнение необходимых этапов. В приведённом выше примере, если вы укажете Ant завершить этап compile, программа определит, что сначала должны быть выполнены цели init и preprocess. Цель init ни от чего не зависит, поэтому будет выполняться первой. Затем Ant рассмотрит цель preprocess и определит, что она зависит от цели init; поскольку она уже была выполнена, Ant выполняет цель preprocess. Наконец, может быть выполнено само задание compile. Обратите внимание на то, что порядок, в котором цели появляются в файле компоновки, не важен — порядок выполнения определяют только атрибуты depends.

Примером типичного файла компоновки веб-архивов является build.xml из ар-

хива примеров на сайте www.sun.com/javaee/downloads.

<project default="install">

<property environment="env"/> <property file="build.properties"/>

<property name="appdir" value="${basedir}/${app}"/> <basename property="appname" file="${appdir}"/> <property name="builddir" value="${appdir}/build"/>

<property name="warfile" value="${builddir}/${appname}.war"/>

<path id="classpath">

<pathelement location="${javaee.api.jar}"/> <fileset dir="${appdir}">

<include name="web/WEB-INF/**/*.jar"/> </fileset>

</path>

<target name="init">

209

<!-- fail unless="app" message="Run ant -Dapp=..."/ --> </target>

<target name="prepare" depends="init" description="Create build directory.">

<mkdir dir="${builddir}"/>

<mkdir dir="${builddir}/WEB-INF"/>

<mkdir dir="${builddir}/WEB-INF/classes"/> </target>

<target name="copy" depends="prepare" description="Copy files to build directory.">

<copy todir="${builddir}" failonerror="false" verbose="true">

<fileset dir="${appdir}/web"/> </copy>

<copy todir="${builddir}/WEB-INF/classes" failonerror="false" verbose="true">

<fileset dir="${appdir}/src/java"> <exclude name="**/*.java"/>

</fileset>

</copy>

<copy todir="${builddir}/WEB-INF" failonerror="false" verbose="true">

<fileset dir="${appdir}"> <include name="lib/**"/>

</fileset>

</copy>

</target>

<target name="compile" depends="copy" description="Compile source files.">

<javac srcdir="${appdir}/src/java"

destdir="${builddir}/WEB-INF/classes" debug="true"

deprecation="true">

<compilerarg value="-Xlint:unchecked"/> <include name="**/*.java"/>

<classpath refid="classpath"/> </javac>

</target>

<target name="war" depends="compile" description="Build WAR file.">

<delete file="${warfile}"/>

210

<jar jarfile="${warfile}" basedir="${builddir}"/> </target>

<target name="install" depends="war" description="Deploy web application.">

<copy file="${warfile}" todir="${deploy.dir}"/> </target>

<target name="clean" depends="init" description="Clean everything.">

<delete dir="${builddir}"/> </target>

</project>

Файл build.properties имеет следующее содержание:

appserver.dir=${env.GLASSFISH_HOME} javaee.api.jar=${appserver.dir}/lib/javaee.jar deploy.dir=${appserver.dir}/domains/domain1/autodeploy

Вызов на исполнение производится командой: ant -Dпуть_к_приложению

Например:

ant -Dapp=ch1/login

Утилита создает нужную структуру папок, производит компиляцию всех java-

файлов в классы, создает WAR-архив и помещает его в папку /domains/domain1/ autodeploy сервера приложений на вашем компьютере, что автоматически приводит к развертыванию приложения на сервере.

211