Защита
Защищенность J2EE приложения поддерживается несколькими способами.
- С помощью определения методов аутентификации, т.е. определения идентичности пользователей. Эти методы определяются в дескрипторе развертывания приложения. Можно использовать следующие способы аутентификации.
- Отсутствие аутентификации.
- С помощью базового механизма протокола HTTP. При попытке обращения к ресурсу по протоколу HTTP будет запрошено имя пользователя и пароль, которые будут проверены Web-сервером. Этот способ не слишком хорошо защищен, поскольку реквизиты пользователя пересылаются по сети в незашифрованном виде.
- С помощью дайджеста (digest). Этот метод работает так же, как базовый механизм аутентификации по HTTP, но имя и пароль пользователя пересылаются в зашифрованном виде. Такой способ используется достаточно редко.
- С помощью специальной формы. При этом определяется страница, на которой расположена форма аутентификации (обычно это те же поля для ввода имени пользователя и пароля, но, может быть, и каких-то других его атрибутов), и страница, на которой находится сообщение, выдаваемое при неудачной аутентификации.
- С использованием сертификата клиента. Этот метод требует использовать протокол HTTPS. Клиент должен предоставить свой сертификат или открытый ключ, удовлетворяющий стандарту X.509 на инфраструктуру открытых ключей. Можно использовать и взаимную аутентификацию — в этом случае и клиент, и сервер предоставляют свои сертификаты.
- С помощью соединений по протоколу HTTP поверх уровня защищенных сокетов (Secure Socket Layer, SSL, на HTTP поверх SSL часто ссылаются с помощью отдельной аббревиатуры HTTPS).
Можно потребовать использовать только такие соединения, указав атрибуты CONFIDENTIAL и/или INTEGRAL в дескрипторе развертывания приложения. Первый атрибут означает, что данные, передаваемые между клиентом и приложением, будут зашифрованы, так что их тяжело будет прочитать третьей стороне. Второй атрибут означает, что эти данные будут сопровождаться дополнительной информацией, гарантирующей их целостность, т.е.
то, что они не были подменены где-то между участвующими в связи сторонами. - C помощью механизма описания ролей, определения доступности различных методов Web-компонентов и EJB-компонентов для разных ролей, а также задания политик переноса или создания ролей при совместной работе нескольких методов. Роли, политики их переноса и правила доступа различных ролей к методам описываются в дескрипторах развертывания компонентов.
При развертывании приложения зарегистрированные на J2EE-сервере пользователи и группы пользователей могут быть отображены на различные роли, определенные в приложении. - С помощью определения ограничений доступа к наборам ресурсов, задаваемых в виде списков унифицированных идентификаторов ресурсов (URI) или шаблонов URI. Эти ограничения описываются в дескрипторе развертывания приложения и определяют роли и разрешенные им виды прямого доступа (не через обращение к другим компонентам) к данному набору URI.
- С помощью программного определения ролей и пользователей, от имени которых работает текущий поток, из кода самих компонентов.
Это можно делать при помощи методов isUserInRole() и getUserPrincipal() интерфейса HTTPServletRequest, используемого для представления запросов к Web-компонентам, и аналогичных методов isCallerInRole() и getCallerPrincipal() интерфейса EJBContext, используемого для описания контекста выполнения методов EJB-компонентов.
