Настройка механизма безопасности, управляемого контейнером, с помощью AuthenticRoast

Проект с открытым кодом упрощает разработку модуля безопасности JEE

AuthenticRoast ― это проект по разработке ПО с открытым кодом, которое работает с контейнерами Java™ Authentication Service Provider Interface for Containers (JSR 196) и позволяет создавать специальные модули проверки подлинности для управляемых контейнером систем декларативной безопасности. Джо Сэм Шира показывает, как AuthenticRoast помогает минимизировать влияние контейнеров Java Enterprise Edition (JEE) на конфигурацию и значительно уменьшить объем работы по написанию кода, удовлетворяющего особым требованиям безопасности. Предоставляется загружаемый WAR-файл с демонстрационным кодом.

Джо Сэм Шира, разработчик и руководитель, conceptGO

Джо Сэм ШираДжо Сэм Шира (Joe Sam Shirah)— руководитель и разработчик компании conceptGO. Он написал несколько руководств для developerWorks и сайта Oracle Java Developer и был удостоен премии Java Community Award. Является модератором форума developerWorks по Java-фильтрам и ведет разделы FAQ по jGuru JDBC, I18N и Java400.



17.01.2012

Некоторое время назад двое из моих клиентов попросили создать специальную схему безопасности для Web-приложений. Один клиент в новом проекте работал главным образом с IBM i и хотел, чтобы пользователи обращались к приложению через свои учетные записи IBM i. Другой хотел расширить существующее приложение, так чтобы некоторые пользователи могли входить из защищенной базы данных, в то время как «стандартные» пользователи проверялись бы через существующие записи Lightweight Directory Access Protocol (LDAP).

Оба проекта были корпоративными производственными приложениями — не общедоступными Web-сайтами, — и их пользователи работали локально или через виртуальную частную сеть. Обычно в этих условиях хорошо работают схемы безопасности, управляемые контейнером, избавляя приложение от фильтров или другого кода для проверки учетных данных на каждой странице. Проблема новых требований заключалась в том, что модули безопасности, управляемые контейнером, обычно регулируются областями (realms) — механизмами ввода данных о пользователях, предоставляемыми контейнером, таким как Apache Tomcat, IBM WebSphere или GlassFish. Области и их реализации разнообразны и, как правило, специфичны для конкретного контейнера. Эти же приложения должны работать в GlassFish, где не существует никаких областей для доступа к учетным данным IBM i или разных методов аутентификации и авторизации в пределах одной области.

Моей задачей было создать специальный механизм аутентификации и авторизации пользователей, а затем передать задачи обеспечения безопасности модулю, управляемому контейнером. В этой статье я описываю, как через Java Authentication and Authorization Service (JAAS) и JSR 196 я пришел к решению с применением проекта AuthenticRoast, лицензируемого на условиях GNU Lesser General Public License. В статье используется демонстрационный WAR-файл, который работает в GlassFish (см. раздел Загрузки). Сначала я сделаю краткий обзор механизмов безопасности, управляемых контейнером, с упором на проверку подлинности на основе форм.

Концепции механизмов безопасности, управляемых контейнером

Управляемые контейнером механизмы безопасности ― это механизмы декларативной безопасности, описанные в спецификации Java Servlet (см. раздел Ресурсы). Когда они соответствуют потребностям приложения, то избавляют программиста от большого объема утомительной, чреватой ошибками работы. Они могут также обеспечить согласованность процессов аутентификации и авторизации для нескольких приложений.

Роли

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

Идея систем безопасности, управляемых контейнером, заключается в том, что пользователи и роли определены вне приложения, и существует стандартный метод получения учетных данных. Защищаемые Web-страницы также определены снаружи и доступны только для авторизованных пользователей или ролей. Управляемый контейнером механизм безопасности автоматически управляет доступом с помощью объявленных ролей, которые отображаются на страницы или группы страниц.

Спецификация сервлетов определяет четыре типа проверки подлинности:

  • HTTP Basic Authentication
  • HTTP Digest Authentication
  • HTTPS Client Authentication
  • Form Based Authentication

Спецификация включает также твердую рекомендацию, чтобы в сервере приложений был реализован профиль контейнера сервлетов Java Authentication SPI for Containers, как указано в JSR 196 (см. раздел Ресурсы).

После проверки подлинности пользователя можно применять следующие методы HttpServletRequest для более точного управления определенными элементами страницы:

  • getRemoteUser()
  • getUserPrincipal()
  • isUserInRole(java.lang.String role)

Настройка

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

В последних версиях спецификации Servlet есть аннотации и другие программные методы для определения ограничений безопасности, но я использую декларации в файле web.xml — потому что они знакомы, находятся в одном месте и доступны тем, кто отвечает за развертывание и администрирование приложений. Дополнительные элементы, дочерние элементы и детали, не используемые в этой статье, можно найти по ссылкам, приведенным в разделе Ресурсы

Ограничения безопасности

Элемент <security-constraint> файла web.xml указывает страницы, которые требуется защищать, и роли, которым разрешен доступ к этим страницам. В листинге 1 приведен пример.

Листинг 1. Элемент <security-constraint>
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Protected Pages</web-resource-name>
        <url-pattern>/protected/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>boss</role-name> 
        <role-name>mgr</role-name> 
        <role-name>user</role-name> 
    </auth-constraint>
</security-constraint>

Подэлемент <web-resource-collection> указывает коллекцию и определяет один или несколько элементов <url-pattern>, которые должны быть защищены. В примере, приведенном в листинге 1, коллекция называется Protected Pages. Все страницы в защищенном каталоге относятся к подэлементу <auth-constraint>, указывающему имена ролей, которым разрешен доступ. В демонстрационном коде это роли boss, mgr и user. Обратите внимание, что HTTP-методы всех типов —GET, POST и т.п. — по умолчанию также подвержены ограничению; при необходимости можно добавить или исключить отдельные типы.

Роли безопасности

Элементы <security-role> в листинге 2 содержат определения ролей, перечисленных в подэлементах <auth-constraint> из листинга 1.

Листинг 2. Элементы <security-role>
<security-role> 
    <description>boss</description>
    <role-name>boss</role-name>
</security-role> 
<security-role> 
    <description>mgr</description>
    <role-name>mgr</role-name>
</security-role> 
<security-role> 
    <description>user</description>
    <role-name>user</role-name>
</security-role>

Проверка подлинности на основе форм

Проверка подлинности на основе форм позволяет настраивать пользовательский интерфейс для механизмов безопасности, управляемых контейнером. Как показано в листинге 3, элемент <form /> должен использовать метод POST и действие j_security_check. Форма должна также включать элементы <input /> с именами j_username и j_password для проверяемых идентификатора и пароля.

Листинг 3. Минимальные требования к Web-странице проверки подлинности на основе форм
<form method="POST" action="j_security_check"> 
<input type="text" name="j_username"> 
<input type="password" name="j_password"> 
</form>

Если Web-страница отвечает этим минимальным требованиям, то можно добавить все необходимое, чтобы соответствовать стандартам своего приложения. например, на рисунке 1 показана страница входа для демонстрационного кода. Она включает в себя заголовок с изображением, метки и инструкции.

Рисунок 1. Страница входа dwAuthenticRoastDemo
Снимок с экрана демонстрационной страницы входа AuthenticRoast

Выход обычно осуществляется путем объявления сеанса недействительным. Вместо этого можно использовать метод HttpServletRequest logout() или дополнить объявление сеанса недействительным сбросом удостоверения вызывающей стороны.

Стандартный механизм безопасности, управляемый контейнером, также требует наличия записи <login-config /> в файле web.xml, как показано в листинге 4.

Листинг 4. Пример записи <login-config /> в файле web.xml
<login-config>
    <auth-method>FORM</auth-method>
    <realm-name>SomeRealmName</realm-name>
    <form-login-config>
        <form-login-page>/login.jsp</form-login-page>
        <form-error-page>/login-error.jsp</form-error-page>
    </form-login-config>
</login-config>

Запись <login-config /> определяет метод и область проверки подлинности. Так как в этом примере используется метод на основе формы, необходим элемент <form-login-config /> для определения страниц, используемых для входа в систему и сообщений об ошибках.

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


Проблема JAAS

JAAS ― это низкоуровневый API — встроенный в Java SE, начиная с версии 1.4, — для разработки модулей аутентификации и авторизации (см. раздел Ресурсы. Первым решением, которое пришло на ум для моих проектов, был JAAS; это гибкий инструмент, который допускает подключаемые модули и является стандартной частью Java SE.

К сожалению, JAAS был определен до появления механизмов безопасности JEE. JAAS хорошо работает в автономных приложениях, но лишен стандартных средств интеграции или связывания с сервлетами и JEE-приложениями. К тому же он строит роли на основе класса javax.security.auth.Subject, который содержит несколько принципалов, тогда как механизм безопасности, управляемый контейнером, работает с классом java.security.Principal.

В отсутствие стандарта интеграции любая поддержка JAAS поставщиками сервлетов или JEE-контейнеров будет проприетарной. В некотором смысле это та же проблема областей, но я решил прибегнуть к проприетарному JAAS или своей собственной реализации JAAS только в том случае, если не найдется лучшего, более стандартизованного решения.


Спасение - в JSR 196?

Java Authentication Service Provider Interface for Containers иногда называют JASPI или JASPIC, но известнее он как JSR 196. Его цель заключается в том, чтобы указать стандарт, позволяющий настраивать механизмы проверки подлинности, которые совместимый контейнер будет использовать для обеспечения декларативной безопасности. JSR определяет профили различных контекстов, включая сервлеты.

Я слышал о JSR 196 еще в 2004 году, но до выхода окончательного проекта в 2007 году он томился в Java Community Process. В то же время GlassFish, как эталонная реализация JEE, поддерживает часть JSR, относящуюся к Servlet Container Profile, по крайней мере, начиная с версии 2.1. JSR 196 входит в спецификацию JEE 6 (см. раздел Ресурсы).

В дополнение к обычному жаргону безопасности и четкому следованию концепции Server Authentication Module (SAM) JSR 196 использует множество иногда ничего не говорящих выражений, таких как message authentication modules, message processing runtimes или Java Authorization Contract for Containers (JACC, или Java ACC). Несмотря на это, я был готов пройти через этот процесс, пока не наткнулся на две серьезные проблемы:

  • каждый SAM должен быть настроен и эффективно интегрирован не только в приложение, но и в контейнер;
  • проделать все шаги, приведенные в примерах — таких как рекомендации Enterprise Tech Tip "Adding Authentication Mechanisms to the GlassFish Servlet Container" от руководителя группы разработчиков JSR 196 (см. раздел Resources), — очень большая работа.

Я все же хотел по возможности использовать методы JSR 196, но мне нужен был способ минимизировать объем работы по реализации SAM. После еще одного цикла поиска я обнаружил проект open source, который ставит перед собой именно эту цель.


AuthenticRoast

На момент написания статьи проект AuthenticRoast (см. раздел Ресурсы) находится на этапе версии 0.3.3 , но он уже более трех лет используется в производстве. В моих двух проектах он применяется соответственно два года и один год.

AuthenticRoast состоит из трех основных JAR-файлов, и работа разделена на две части:

С какими контейнерами работает AuthenticRoast?

AuthenticRoast протестирован с GlassFish 2.x/3.x и Tomcat 6. (Версия для Tomcat ― это "клапан", использующий внутренние вызовы, потому что в Tomcat нет внутренней поддержки JSR 196). Версия для GlassFish или JSR 196 должна работать с любым JEE 6-совместимым контейнером, таким как WebSphere 8. Однако я не нашел в Интернете сообщений о ее использовании на каких-либо серверах, кроме GlassFish.

Чтобы использовать AuthenticRoast с другим контейнером, нужно как минимум перевести регистрацию базового модуля в формат Message Security Configuration GlassFish. Кроме того, нужно преобразовать httpservlet-security-provider из файла glassfish-web.xml в эквивалент для вашего контейнера. В случае WebSphere связь с источником приложения осуществляется с помощью параметра Map JASPI Provider консоли администрирования (см. раздел Ресурсы).

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

  • AuthenticRoast-API-ver.jar и AuthenticRoast-Impl-ver.jar: Интеграции с контейнером избежать нельзя, но следующие JAR-файлы:
    • обеспечивают одноразовую настройку контейнера;
    • служат связующим звеном между контейнером и модулями безопасности вашего приложения (аутентификаторами).
  • AuthenticRoast-Extras-ver.jar: несмотря на название, этот JAR применяется в большинстве приложений (если только вы не пожелаете написать свой собственный код), так как содержит следующие абстрактные классы для различных типов аутентификации, используемые в механизме безопасности, управляемом контейнером:
    • BasicAuthenticator
    • CompositeAuthenticator
    • FormAuthenticator
    • SSLClientAuthenticator
    • TicketAuthenticator

В оставшейся части этой статьи и в демонстрационном коде я покажу, как использовать класс FormAuthenticator с GlassFish 3.1.1.

Процесс разработки механизма аутентификации AuthenticRoast состоит из четырех частей:

  • настройка контейнера;
  • настройка приложения;
  • регистрация аутентификатора;
  • программирование аутентификатора.

Я опишу их по порядку.


Настройка контейнера

К счастью, настройка контейнера (в данном случае GlassFish) ― единовременная задача, решаемая с помощью AuthenticRoast. Страница InstallationForGlassfish в вики проекта (см. раздел Ресурсы) проста и понятна, и я отсылаю вас за инструкциями по настройке к ней, потому что там могут быть изменения. Эти инструкции рассчитаны на GlassFish 2.x, так что на рисунках 2, 3, 4 и 5 показаны отличия для GlassFish 3.1.1. Перед началом процесса скопируйте AuthenticRoast-API-ver.jar и AuthenticRoast-Impl-ver.jar в папку lib установки GlassFish и перезапустите сервер.

Как показано на рисунке 2, выбрав Message Security, можно убедиться, что уровень проверки подлинности HttpServlet уже существует. Щелкните на HttpServlet.

Рисунок 2. Страница Message Security Configurations GlassFish 3.1.1
Страница Message Security Configurations GlassFish 3.1.1

Появится страница Edit Message Security Configuration, показанная на рисунке 3.

Рисунок 3. Страница Edit Message Security Configurations GlassFish 3.1.1
Страница Edit Message Security Configurations GlassFish 3.1.1

Выберите вкладку Providers.

На рисунке 4 показано, почему уровень проверки подлинности HttpServlet уже существует: консоль администратора GlassFish теперь сама использует источник данных по безопасности. На этом рисунке показано также, что я уже создал источник roast. Добавьте его, нажав кнопку New.

Рисунок 4. Страница Provider Configurations GlassFish 3.1.1
Страница Provider Configurations GlassFish 3.1.1

На рисунке 5 видны записи для источника roast. Они же приведены на странице вики AuthenticRoast InstallationForGlassfish. Оставьте поля Response Policy внизу страницы (не показаны на рисунке 5) пустыми.

Рисунок 5. Страница Edit Provider Configurations GlassFish 3.1.1
Страница Edit Provider Configurations GlassFish 3.1.1

Сохраните конфигурацию и перезапустите сервер. После этого AuthenticRoast можно использовать в своих приложениях.


Настройка приложения

Файл web.xml для приложения, в котором используется AuthenticRoast, соответствует стандарту механизмов безопасности, управляемых контейнером, как показано в листинге 1 и листинге 2. Однако есть одно исключение: AuthenticRoast не требует и не использует элемент <form-login-config /> из листинга 4.

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

Листинг 5. Запись определения прослушивателя приложения в файле web.xml
<listener>
  <listener-class>com.dw.ARDAppInit</listener-class>
</listener>

В последней части процесса необходимой настройки приложение сообщает контейнеру, что оно использует источник данных по безопасности httpservlet. Атрибут httpservlet-security-provider элемента <glassfish-web-app /> в зависящем от контейнера файле glassfish-web.xml (в версиях до GlassFish 3.x он называется sun-web.xml) решает эту задачу с помощью записи (roast), соответствующей определенному идентификатору источника:

<glassfish-web-app httpservlet-security-provider="roast" error-url="">

Отображение ролей — необязательная, но полезная функция JEE. Она позволяет ответственным за развертывание ставить различные группы или роли в соответствие тем, которые используются в приложении. К сожалению, конкретные записи и пути зависят от контейнера; в WebSphere, например, используется ibm-application-bnd.xml, а в GlassFish опять же glassfish-web.xml. В листинге 6 приведены записи для отображения элементов <role-name />, используемых в приложении, на имена групп <group-name />, зависящие от установки-предприятия.

Листинг 6. Отображение ролей в файле glassfish-web.xml
<security-role-mapping>
    <role-name>boss</role-name>
    <group-name>ARDBoss</group-name>
</security-role-mapping>
<security-role-mapping>
    <role-name>mgr</role-name>
    <group-name>ARDMgr</group-name>
</security-role-mapping>
<security-role-mapping>
    <role-name>user</role-name>
    <group-name>ARDUser</group-name>
</security-role-mapping>

В результате этих записей, когда демонстрационное приложение, например, обращается к boss, контейнер гарантирует выбор роли ARDBoss.


Регистрация аутентификатора

ARDAppInit ― это прослушиватель из примера демоприложения, определенный в листинге 5. Как видно из листинга 7, он использует метод contextInitialized() для регистрации экземпляра класса authenticator во время запуска приложения.

Листинг 7. Демокод регистрации аутентификатора
package com.dw;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import name.aikesommer.authenticator.Registry;
...
public class ARDAppInit implements ServletContextListener
{
  ...
  public void contextInitialized( ServletContextEvent sce )
  {
    ServletContext sc = null;

    sc = sce.getServletContext();
    // регистрация аутентификатора AuthenticRoast
    Registry.forContext( sc ).register( new ARDFormAuthenticator() );

    System.out.println( "[ARDAppInit Executed]" );

  } // конец contextInitialized

} // конец класса ARDAppInit

Этот код, по существу, один и тот же в каждом приложении; обычно изменяются только имена пакета и установки экземпляра аутентификатора.


Код аутентификатора

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

  • расширить класс FormAuthenticator;
  • переопределить максимум четыре — а обычно только два — метода FormAuthenticator;
  • кое-что знать о классе SimplePrincipal.

Класс FormAuthenticator (в AuthenticRoast-Extras-ver.jar)расширяет PluggableAuthenticator, который, наряду с SimplePrincipal расположен в AuthenticRoast-API-ver.jar. Контейнер обращается к методам в экземплярах класса через AuthenticRoast.

Если вы хотите использовать имена login.jsp для своей страницы входа в систему и login-error.jsp для страницы ошибок входа, то вам достаточно двух методов FormAuthenticator. В противном случае переопределите String getErrorPage() и String getLoginPage(), чтобы они возвращали предпочтительные имена этих страниц.

Следующие два метода нужно переопределять всегда:

  • boolean checkCredentials(AuthenticationManager manager, AuthenticationRequest request, String username, String password)

    Метод checkCredentials() отвечает за проверку передаваемых полномочий — то есть имени пользователя и пароля. Он возвращает значение true, если полномочия переданы; в противном случае ― значение false;

  • SimplePrincipal loadPrincipal(AuthenticationManager manager, AuthenticationRequest request, String username)

    Метод loadPrincipal() следует вызывать только в том случае, если checkCredentials() возвратил значение true, указывая, что пользователь проверен. Этот метод возвращает значение SimplePrincipal, которое, по существу, представляет собой имя пользователя, и Set - набор имен групп. Конструктор принимает имя пользователя и массив типа String с именами групп или ролей, связанных с этим пользователем. Контейнер ищет имена групп, совпадающие с ролями, указанными в элементе <auth-constraint> web.xml (см. листинг 1) или в соответствии с отображением (см. листинг 6). В листинге 8 приведен пример загрузки SimplePrincipal.

Листинг 8. Загрузка SimplePrincipal с помощью статического массива
String[] asBossGroups = 
          { "ABCBoss", "ARDBoss", "MVBoss", "RSBoss" }; 

SimplePrincipal sp = new SimplePrincipal( "bossLady", asBossGroups );

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

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


О демонстрационном приложении

Демонстрационное приложение для этой статьи (см. раздел Загрузки) представляет собой конкретный пример использования AuthenticRoast. За исключением страниц проверки логина, оно содержит только одну страницу в защищенном каталоге, которая просто отображает результаты обращений к getRemoteUser(), getUserPrincipal() и isUserInRole(java.lang.String role), как показано на рисунке 6.

Рисунок 6. Страница результата проверки подлинности
Снимок с экрана демонстрационной страницы входа AuthenticRoast

Метод checkCredentials() принимает три набора имен пользователя/паролей:

  • пользователь stevie, пароль user1,
  • пользователь ray, пароль mgr1,
  • пользователь vaughan, пароль boss1.

Если переданные учетные данные прошли проверку, то имя пользователя и связанный с ним массив имен групп из метода loadPrincipal() возвращаются в объект SimplePrincipal:

  • asUserGroups для пользователя stevie,
  • asMgrGroups для пользователя ray,
  • asBossGroups для пользователя vaughan.

Содержимое массива приведено в листинге 9.

Листинг 9. Массивы групп, используемые методом ARDFormAuthenticator
  private static String[] asBossGroups = 
          { "ABCBoss", "ARDBoss", "MVBoss", "RSBoss" }; 
  private static String[] asMgrGroups = 
          { "ABCMgr", "ARDMgr", "MVMgr", "RSMgr" }; 
  private static String[] asUserGroups = 
          { "ABCUser", "ARDUser", "MVUser", "RSUser" };

Почти весь оставшийся код и настройка, включая отображение ролей, показаны в листингах 1 - 7. Исключение, как объяснялось выше, заключается в том, что элемент <login-config />, показанный в листинге 4, не обязателен и в AuthenticRoast не используется.


Заключение

Специальные модули для управляемой контейнером проверки подлинности необходимы лишь изредка, но могут быть очень важны. JSR 196 достигает своей цели ― интеграции для специального декларативного уровня безопасности, но решение может быть громоздким и сложным. Проекта AuthenticRoast упрощает этот процесс.

Имейте в виду, что главное преимущество AuthenticRoast — полный контроль — также является и его главным недостатком: все приходится делать самому. Например, когда выше я использовал область GlassFish LDAP для доступа к Microsoft Active Directory за сведениями о пароле и группах, мне предварительно пришлось изобрести формулу строки поиска. Когда я использовал AuthenticRoast для добавления процесса дополнительной проверки действительности полномочий LDAP, мне пришлось погрузиться в написание собственного кода доступа к LDAP.

Однако этот недостаток относится и к работе непосредственно с JSR 196 и практически с любым другим средством создания специальных модулей обеспечения безопасности. Итак, AuthenticRoast ― это проект с открытым исходным кодом, который успешно минимизирует влияние конфигурации на контейнеры JEE и значительно уменьшает объем работы по написанию кода под ваши требования безопасности.


Загрузка

ОписаниеИмяРазмер
Демонстрационный WAR для этой статьи1j-authenticroast.zip86 КБ

Заметка

  1. В WAR-файл включены исходные коды Java. Инструкция по использованию WAR-файла содержится в файле readme.txt, входящем в загрузку.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, Open source
ArticleID=851389
ArticleTitle=Настройка механизма безопасности, управляемого контейнером, с помощью AuthenticRoast
publish-date=01172012