16. Безопасность веб-приложений
Безопасность заключается в защите данных, чтобы предотвратить несанкцио-
нированный доступ, их повреждение в памяти или при передаче. Application Server основан на динамической, расширяемой архитектуре безопасности в стандарте
Java EE. Встроенные возможности безопасности включают криптографию, аутенти-
фикацию, авторизацию и общую базовую инфраструктуру. Сервер создан в модели
безопасности Java, которая использует среду, где приложения можно запустить безо-
пасно, без потенциального риска для системы или пользователей.
Материал данного раздела предполагает, что вы имеете представление о кон-
цепции безопасности. Чтобы узнать больше о данной концепции, перед началом дан-
ной главы настоятельно рекомендуется изучить документы на сайте http://java.sun. com/javase/6/docs/ technotes/guides/security/. Детальное изложение вопросов безопас-
ности веб-приложений можно найти в [1].
Архитектура службы безопасности основана на использовании ролей и раз-
решений. Роли приписываются пользователям, а разрешения — ресурсам сервера.
Разрешение указывает на роли, которыми должен обладать пользователь, чтобы по-
лучить доступ к данному ресурсу.
16.1. Краткий обзор
Java EE предоставляет набор компонент для развертывания приложений в различных контейнерах, позволяющих создавать многопоточные приложения для предприятий. Безопасность для этих компонент обеспечивается их контейнерами. Контейнер поддерживает два рода безопасности: декларативную и программную.
•Декларативнаябезопасностьобеспечиваетбезопасностькомпонентсисполь-
зованием дескрипторов развертывания. Дескрипторы содержат описание ролей, пользователей и их полномочий. Для поддержки безопасности классов внешних бинов используются аннотации (также называемые метаданными)
внутри этих классов. Аннотации позволяют существенно сократить объем
кода в XML-файлах конфигурации.
•Программная безопасность включается в само приложение и используется для решения вопросов безопасности. Она полезна, когда декларативная безопасность не удовлетворяет нужным требованиям.
Пример обеспечения безопасности
Для большей демонстрации работы безопасности рассмотрим пример просто-
го приложения с клиентом, интерфейсом пользователя JSP и внешних бинов с бизнеслогикой. Клиент обращается к веб-серверу для выполнения аутентификации службой,
содержащей сведения о пользователях, для допуска его в текущей сессии.
Шаг 1 Первичный запрос
На первом шаге клиент посылает запрос на URL приложения (рис. 16.1).
Так как клиент еще не аутентифицирован на сервере, механизм формирования ответа сервера обнаруживает этот факт и вызывает механизм аутентификации для
этого ресурса.
192
Рис. 16.1. Первичный запрос
Шаг 2 Первичная аутентификация
Сервер возвращает форму, заполняемую пользователем: обычно это имя и па-
роль (рис. 16.2).
Рис. 16.2. Первичная аутентификация
Механизм проверки может быть локальным на сервере или поручен службе
безопасности. На основе проверки сервер устанавливает мандат пользователя.
Шаг 3 Авторизация URL
Мандат используется в дальнейшем для допуска пользователя к защищенным ресурсам в его запросах. Сервер консультируется с информацией в дескрипторе раз-
вертывания, ассоциируя ее с ролью клиента в описании ресурса, что позволяет раз-
решить допуск к ресурсу на основе роли и полномочий. Процесс показан на рис.16.3.
Рис. 16.3. URL-авторизация
Веб-сервер завершает авторизацию значением «is authorized», когда уда-
ется сопоставить разрешенные роли ресурса и роли пользователя, иначе — «not authorized».
Шаг 4 Выполнение принятого запроса
Если пользователь авторизован, сервер возвращает результат исходного за-
проса, как показано на рис. 16.4.
Рис. 16.4. Исполнение исходного запроса
193
В этом примере ответ на URL-страницы JSP возвращается клиенту, позволяя
ему заполнять поля на форме и отправлять их на сервер для использования в бизнеслогике приложения.
Шаг 5 Вызов бинов бизнес-логики
Страница JSP вызывает метод бина, используя мандат пользователя для уста-
новления ассоциации безопасности между JSP-страницей и бином, показанной на рис. 16.5. Ассоциация сопоставляет два контекста безопасности: сервера и контейне-
ра EJB.
Рис. 16.5. Исполнение исходного запроса
Контейнер EJB выполняет проверку контроля доступа для метода бина. Он запрашивает политику безопасности (из дескриптора развертывания), связанную с би-
ном, для определения ролей и разрешений. Каждую роль метода контейнер EJB сопо-
ставляет с ролью клиента.
По аналогии, контейнер возвращает значение «is authorized» или «not authorized», что и определяет право на использование вызова метода страницей
JSP.
Функции безопасности
Механизм обеспечения безопасности выполняет следующие функции:
•предотвращает неавторизованный доступ к функциям приложения, персональным или коммерческим данным;
•хранит регистрацию пользователей для выполнения ими операций;
•защищает систему от прерывания обслуживания и других брешей для повы-
шения качества обслуживания клиентов;
•обеспечивает легкость администрирования и прозрачность для пользовате-
лей системы.
16.2.Механизмы обеспечения безопасности
Поддержка безопасности Java EE включает следующие функции:
Java Authentication and Authorization Service (JAAS): набор API для аутенти-
фикации и контроля доступа пользователей. Обеспечивает вставляемый и расширяе-
мый инструмент для программной безопасности. JAAS — ядро Java SE API и техноло-
гия низкого уровня для механизма безопасности Java EE.
Java Generic Security Services (Java GSS-API): Java GSS-API — основанный на жетонах набор API для безопасного обмена сообщениями между взаимодействую-
194
щими приложениями. Поддерживает унифицированный программный доступ к серви-
су различных механизмов, включая Kerberos.
Java Cryptography Extension (JCE) обеспечивает инструмент для шифрова-
ния, генерации ключей, для выполнения соглашений о ключах, алгоритм Message
Authentication Code (MAC). Поддерживает симметричное и несимметричное шифрова-
ние, блокирование и потоки цифровых данных. Блок цифровых данных обрабатывает
группу байт потока побайтно. Поддерживаются секретные потоки данных и опечатанные объекты.
Java Secure Sockets Extension (JSSE) обеспечивает инструмент для Java вер-
сии протоколов SSL и TSL и включает функции шифрования, аутентификацию сер-
вера, интеграцию сообщений и аутентификацию клиента, обеспечивая безопасность
интернет-коммуникаций.
Simple Authentication and Security Layer (SASL) является стандартом
интернет-спецификации протокола для аутентификации и слоя установления секрет-
ности между клиентом и сервером приложений (RFC 2222). Определяет способ обме-
на данными, а не их содержание.
16.2.1. Использование декларативной безопасности
Декларативнаябезопасность—быстрыйспособконтроляполномочийсисполь- зованием конфигурирования параметров безопасности в дескрипторе развертывания. В период исполнения приложения сервер читает данные дескриптора и исполняет приложение, модуль или компонент соответственно. Дескриптор содержит информа-
цию, не указанную в аннотациях или принимаемую по умолчанию.
Использование аннотаций
Аннотации позволяют декларировать нужные данные прямо в тексте приложе-
ний для декларативной и программной безопасности. При развертывании приложения
эта информация анализируется сервером. Аннотации позволяют избегать написания запутанных кодов для обеспечения нужных функций.
16.2.2. Использование программируемой безопасности
Программируемая безопасность — вставки кода в приложение, используемые для принятия решений о безопасности. Полезна, когда декларативная безопасность
недостаточна, чтобы отражать модель безопасности приложения. API для программи-
руемой безопасности состоит из двух методов интерфейса EJBContext и шести методов интерфейса servlet HttpServletRequest. Эти методы позволяют принимать логиче-
ские решения, основанные на роли безопасности оператора вызова или удалённого
пользователя.
16.3. Безопасность сервера предприятия
При развертывании приложения сервер Sun GlassFish Enterprise Server v3
обеспечивает высокую защиту, взаимодействие и распределенные вычисления, основанные на модели безопасности Java EE. Сервер предприятия поддерживает модель
безопасности Java EE 6. Вы можете сориентировать сервер на следующие цели:
•добавление, удаление или модификация зарегистрированных пользователей;
•конфигурирование слушателей HTTP и IIOP;
•конфигурирование безопасности коннекторов JavaManagement (JMX);
195
•добавление, удаление или модификация существующих или требуемых об-
ластей;
•определение интерфейса для сменных поставщиков авторизации с исполь-
зованием Java Authorization Contract for Containers (JACC). JACC определяет
контракты безопасности между сервером и модулем полиса разрешения. Эти
контракты определяют, как установлены, сконфигурированы и используются
провайдеры разрешений в ограничениях доступа;
•использование сменных модулей проверки;
•модификация разработчиком механизма аутентификации. Требуется, чтобы
все реализации контейнеров Java EE 6 поддержали Servlet Profile of JSR–196, который содержит способ модификации механизма аутентификации, приме-
няемый контейнером веб от имени одного или более приложений;
•установка и изменение полиса для приложения.
16.3.1. Работа с областями, пользователями, группами и ролями
Вам часто нужно защищать ресурсы для гарантии, что только зарегистрированные пользователи имеют к ним доступ.
Авторизация обеспечивает управляемый доступ к защищенным ресурсам.
Разрешение основано на идентификации и аутентификации. Идентификация явля-
ется процессом, который позволяет опознавание объекта системой, а аутентификация является процессом, который проверяет тождество пользователя, устройства или другого объекта в компьютерной системе как предварительное условие для доступа к ресурсам в системе.
Эта секция обсуждает установки разрешений пользователям, чтобы они пра-
вильно идентифицировались и получали доступ к защищаемым ресурсам или запрет доступа, если пользователь не имеет допуск к защищенным ресурсам. Чтобы аутентифицировать пользователя, нужно выполнить следующие шаги.
1.Разработчик приложения пишет код для запроса клиента на ввод имени и
пароля.
2.Разработчик приложения сообщает, как установить параметры безопасности при развертывании приложения с использованием дескриптора развертывания или аннотаций.
3.Администратор сервера регистрирует пользователей и группы на сервере предприятия.
4.Разработчик приложения задаёт для ресурсов допустимые роли безопасности пользователей, групп и принципалов, определённые на сервере.
16.3.2. Понятие пользователей, групп, ролей и разрешений
Сервер осуществляет аутентификацию и контролирует полисы разрешения
для следующих объектов (рис. 16.6).
Пользователи (Users) — лица, определённые на сервере приложений. В об-
щих чертах, пользователь — человек, программный компонент (например, бин или
сервис). Допущенный пользователь иногда называется принципалом (principal) или
субъектом. Сервис аутентификации управляет пользователями с использованием разных областей.
Группы (Groups) — набор пользователей на сервере, характеризуемых об-
щими признаками. Группы позволяют облегчить контроль доступа большому числу
однородных пользователей.
196
Рис. 16.6. Соответствие ролей, пользователей и групп
Роли (Roles) — поименованный уровень разрешения, определённый в прило-
жении. Роль может быть аналогичной ключу, который открывает блокировку. Много
людей могут иметь копию ключа. Блокировке все равно, кто имеет доступ, необходимо
только, чтобы подходил ключ на право использования. Роли определяются в дескрипторе развертывания приложений.
Области (Realms) — хранилища, содержащие информацию о пользователях,
группахисвязанныхснимимандатахбезопасности.Областьтакженазываютдоменом полиса безопасности. Сервер при установке имеет следующие области: file, certificate и admin-realm. Дополнительно возможны ldap, solaris и custom. Приложение может задавать дополнительные области в дескрипторе развертывания.
Вфайловой области сервер хранит мандаты пользователя локально в файле keyfile. Вы можете использовать консоль администратора, чтобы управлять пользователями в файловой области.
Вобласти сертификатов сервер хранит мандаты пользователя в базе данных сертификатов. При использовании области сертификатов сервер использует сертифи-
каты с протоколом HTTPS, чтобы аутентифицировать веб-клиентов.
Вобласти admin-realm, так же как и в области FileRealm, мандаты хранятся ло-
кально в файле admin-keyfile. Для управления пользователями в этой области используется консоль администратора.
Добавление пользователя на сервере
1.В административной консоли с правами администратора перейти в узел
Configuration/Security/Realms/
2.В зависимости от потребности перейти в узел file realm, admin realm или certificate realm.
3.Перейти в Manage Users/New/ и заполнить поля формы UserID, Password и Groups.
Установка ролей пользователям
Для приложений роли указываются в файле развертывания application.xml. Соответствие ролей и пользователей указывается в файле развертывания sun-application.xml. Для индивидуальных модулей роли определяются в файле web.xml или ejb-jar.xml, а соответствие — в файле sun-web.xml или sun-ejb-jar.xml.
197
Пример ограничения безопасности для роли DEPT-ADMIN на просмотр данных
служащих и роли DIRECTOR на редактирование данных, в котором соответствующий
бин имеет аннотации для класса и методов экземпляра:
@DeclareRoles({"DEPT-ADMIN", "DIRECTOR"})
@Stateless public class PayrollBean implements Payroll { @Resource SessionContext ctx;
@RolesAllowed("DEPT-ADMIN")
public void reviewEmployeeInfo(EmplInfo info) { oldInfo = ... read from database;
/...
}
@RolesAllowed("DIRECTOR")
public void updateEmployeeInfo(EmplInfo info) { newInfo = ... update database;
...
}
...
}
Дескриптор развертывания web.xml имеет следующий вид:
<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> <security-constraint>
<web-resource-collection>
<web-resource-name>change dept data</web-resource-name> <url-pattern>/hr/employee/*</url-pattern> <http-method>GET</http-method> <http-method>PUT</http-method>
</web-resource-collection> <auth-constraint>
<role-name>DIRECTOR</role-name> </auth-constraint> <user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint>
</security-constraint>
198
Соответствие ролей для пользователей и групп
Для задания соответствия используется элемент security-role-mapping в файлах sun-application.xml, sun-web.xml или sun-ejb-jar.xml. Пример для файла sun-web.xml:
<sun-web-app> <security-role-mapping>
<role-name>DIRECTOR</role-name> <principal-name>schwartz</principal-name>
</security-role-mapping> <security-role-mapping>
<role-name>DEPT-ADMIN</role-name> <group-name>dept-admins</group-name>
</security-role-mapping> </sun-web-app>
Роль DIRECTOR назначается персонально клиенту schwartz, а роль DEPT-
ADMIN — группе клиентов dept-admins.
16.3.3. Задание механизма аутентификации
Элемент login configurationнезависим от элемента security-constraint, так как мо-
жет иметь много ограничений безопасности, применимых ко многим ресурсам, но тот
же метод аутентификации будет относиться ко всем ограничениям на ресурсы в приложении. Элемент login-config используется для определения метода аутентификации пользователя, который нужно использовать для доступа к содержимому области, к которой пользователь будет допущен (в случае базовой аутентификации). Пользователь
должен быть аутентифицирован перед доступом к любому ресурсу, который контроли-
руется ограничением безопасности.
Подэлемент auth-method конфигурирует механизм аутентификации в вебприложении. Элемент должен задавать метод NONE, BASIC, DIGEST, FORM или CLIENT-CERT. Элемент realm-name указывает имя области для использования с ба-
зовой аутентификацией для веб-приложения. Элемент form-login-config определяет
страницы входа и ошибки, которые должны быть использованы в FORM.
Когда вы пытаетесь получить доступ к веб-ресурсу, который защищен элементом form-login-config, контейнер веб активизирует механизм аутентификации, сориентированный на этот ресурс. Выбранный механизм аутентификации определяет, каким
образом пользователь будет уведомлен, чтобы войти в систему. Если элемент <loginconfig> присутствует, а элемент <auth-method> содержит значение кроме NONE, поль-
зователь должен быть удостоверен прежде, чем он получит доступ к любому ресурсу,
который защищен использованием элемента security-constraint в том же дескрипторе
развертывания. Если вы не определяете механизм аутентификации, аутентификации
пользователя не требуется.
Базовая аутентификация протокола HTTP
Задание HTTP Basic Authentication требует, чтобы сервер запросил имя поль-
зователя и пароль у клиента веб и проверил, что имя пользователя и пароль будет в
силе при сравнении их в базе данных зарегистрированных пользователей в заданной
области.
Когда объявлена базовая аутентификация, происходят следующие действия:
1.Клиент запрашивает доступ к защищенному ресурсу.
2.Сервер веб возвращает диалоговое окно, которое запрашивает имя пользо-
вателя и пароль.
199
3.Клиент передает имя пользователя и пароль в сервер.
4.Сервер удостоверяет пользователя в определённой области, и если успешно,
то возвращает запрошенный ресурс.
Следующий пример показывает, как задать базовую аутентификацию в вашем
дескрипторе развертывания:
<login-config> <auth-method>BASIC</auth-method> <realm-name>file</realm-name>
</login-config>
Базовая аутентификация HTTP не является безопасным механизмом аутенти-
фикации. Базовая аутентификация посылает имена пользователя и пароли в Интернет
как открытый текст в кодировке Base64, и целевой сервер не проверяется на подлинность. Эта форма аутентификации при перехвате пакетов может скомпрометировать
имя пользователя и пароль.
Аутентификация на основе формы
Аутентификация с использованием формы позволяет разработчику управлять видом экрана аутентификации входа, модифицировать экран входа и страницы ошиб-
ки по своему усмотрению, которое браузер HTTP предоставляет конечному пользователю. Когда используется аутентификация на основе формы, происходят следующие действия:
1.Клиент запрашивает доступ к защищенному ресурсу.
2.Если клиент не авторизован, сервер переназначает клиента на страницу входа.
3.Клиент подает заполненную форму входа на сервер.
4.Сервер пытается авторизовать пользователя:
•если аутентификация прошла успешно, подлинность принципала прове-
рена (гарантия, что именно он в роли, которая уполномочена иметь доступ
к ресурсу). Если пользователь допущен, сервер переназначает клиента в ресурс, используя полученный URL.
•если аутентификация терпит неудачу, клиент пересылается на страницу ошибки.
Следующий пример показывает, как объявлять аутентификацию на базе формы
в дескрипторе развертывания:
<login-config> <auth-method>FORM</auth-method> <realm-name>file</realm-name> <form-login-config>
<form-login-page>/logon.jsp</form-login-page> <form-error-page>/logonError.jsp</form-error-page>
</form-login-config> </login-config>
Страница входа и ошибки определены относительно позиции дескриптора развертывания.
Аутентификация на основе формы небезопасна. Содержимое диалогового окна
пользователя посылается как простой текст, целевой сервер не проверяется. Эта фор-
ма аутентификации может подвергнуть ваши имена пользователя и пароли опасности, если связь не использует SSL. Если кто-нибудь сможет перехватить передачу, имя
пользователя и пароль могут быть легко декодированы. Тем не менее, когда исполь-
200
зован безопасный механизм транспорта, как например, SSL, или безопасность гарантируется на сетевом уровне, например, протоколом IPSEC или VPN, аутентификация
с формой может быть приемлемой.
Использование формы входа
При создании формы входа не забывайте обеспечить поддержку сеанса работы
пользователя с использованием сеансовой информации cookies или SSL.
Для аутентификации атрибут action формы входа должен всегда быть j_security_check. Это ограничение предусмотрено, чтобы форма входа не была обработана никем, кроме этого ресурса, чтобы избежать требования сервера определять
область действия выхода формы. Следующий фрагмент показывает, как должна быть
закодирована форма на HTML-странице входа.
<form method="POST" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input type="submit" ...>
</form>
Аутентификация клиента с использованием протокола HTTPS
Аутентификация требует от клиента наличия сертификата с открытым ключом (Public Key Certificate — PKC). Если вы определяете эту аутентификацию клиента,
веб-сервер удостоверит клиента, использовав его сертификат с открытым ключом.
Аутентификация клиента HTTPS является более безопасным методом аутентификации, чем базовая или аутентификация формой. Она использует протокол HTTP поверх SSL (HTTPS). Протокол технологии SSL обеспечивает шифрование данных, аутентификацию сервера, целостность сообщений и дополнительную аутентифика-
цию клиента для протокола TCP/IP. Вы можете понимать сертификат с открытым клю-
чом как цифровой эквивалент паспорта. Обычно он выпущен надежной организацией, которая называется автором сертификата (certificate authority — CA), и обеспечивает надёжную идентификацию для предъявителя.
Перед аутентификацией клиента с использованием HTTPS вы должны убедить-
ся, что выполнены следующие действия:
1)клиент имеет правильный сертификат;
2)на вашем сервере включена поддержка SSL. Если ваш сервер — GlassFishEnterprise v3, то поддержка SSL уже включена. Если вы используете
другой сервер, обратитесь к документации для этого сервера, чтобы получить
информацию о поддержке SSL.
Следующий пример показывает, как объявить HTTPS-аутентификацию клиента
в вашем дескрипторе развертывания.
<login-config> <auth-method>CLIENT-CERT</auth-method>
</login-config>
Взаимная аутентификация
При взаимной аутентификации сервер и клиент проверяют друг друга. Есть два типа взаимной аутентификации:
•на основе аутентификации сертификатами;
•на основе имени и пароля пользователя.
201