Служба Аутентификации и авторизации Java (JAAS) была представлена как дополнительный пакет Java 2 SDK, Standard Edition (J2SDK), v 1.3. JAAS был интегрирован в Java Standard Edition Комплект разработчика, запускающийся с J2SDK 1.4.

JAAS обеспечивает основанную на предмете авторизацию на аутентифицируемых идентификационных данных. Этот документ сосредотачивается на аспекте аутентификации JAAS, определенно LoginModule интерфейс.

Кто Должен Считать Этот Документ

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

Связанная Документация

Этот документ предполагает, что Вы уже считали следующее:

Справочник JAAS

Это также обсуждает различные классы и интерфейсы в API JAAS. Пожалуйста, сошлитесь на javadocs для спецификации API JAAS для более подробной информации:

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

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

Эти два учебных руководства являются частью GSS-API Java и последовательностью JAAS учебных руководств, которые используют Kerberos как базовую технологию для аутентификации и защищают передачу.

Введение

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

В то время как приложения пишут в LoginContext Прикладной программный интерфейс (API), технологические провайдеры аутентификации реализуют LoginModule интерфейс. A Configuration определяет LoginModule(s) использоваться с определенным приложением входа в систему. Отличающийся LoginModules может быть включен в соответствии с приложением, не требуя никаких модификаций к приложению непосредственно.

LoginContext ответственно за чтение Configuration и инстанцирование указанного LoginModules. Каждый LoginModule инициализируется с a Subject, a CallbackHandler, совместно используемый LoginModule состояние, и LoginModuleСпецифичные опции.

Subject представляет пользователя или службу, в настоящий момент аутентифицируемую, и обновляется a LoginModule с соответствующим Principals и учетные данные, если аутентификация успешно выполняется. LoginModules используют CallbackHandler связываться с пользователями (чтобы запросить имена пользователей и пароли, например), как описано в описании метода входа в систему. Отметьте что CallbackHandler может быть нуль. A LoginModule это требует a CallbackHandler аутентифицировать Subject может бросить a LoginException если это было инициализировано с a null CallbackHandler. LoginModules дополнительно используют общее состояние, чтобы поделиться информацией или данными между собой.

LoginModuleСпецифичные опции представляют опции, сконфигурированные для этого LoginModule во входе в систему Configuration. Опции определяются LoginModule непосредственно и управление поведение в пределах этого. Например, a LoginModule может определить опции, чтобы поддерживать возможности отладки/тестирования. Опции определяются, используя синтаксис значения ключа, такой как debug=true. LoginModule хранит опции как a Map так, чтобы значения могли быть получены, используя ключ. Отметьте, что нет никакого предела числу вариантов a LoginModule хочет определять.

Вызывающее приложение рассматривает процесс аутентификации как единственную работу, вызванную через звонок LoginContext's login метод. Однако, процесс аутентификации в пределах каждого LoginModule продолжается в двух отличных фазах. В первой фазе аутентификации, LoginContext's login метод вызывает login метод каждого LoginModule определенный в Configuration. login метод для a LoginModule выполняет фактическую аутентификацию (запрашивающий и проверяющий пароль например) и сохраняет его состояние аутентификации как частную информацию о состоянии. После того, как законченный, LoginModule's login возвраты метода true (если это успешно выполнялось), или false (если это должно быть проигнорировано), или это бросает a LoginException определить отказ. В случае отказа, LoginModule не должен повторить аутентификацию или представить задержки. Ответственность таких задач принадлежит приложению. Если приложение пытается повторить аутентификацию, каждого LoginModule's login метод вызовут снова.

Во второй фазе, если LoginContext's полная аутентификация, за которой следуют (призывает к соответствующему, требуемому, необходимому, достаточному и дополнительному LoginModules' login методы, за которыми следуют), тогда commit метод для каждого LoginModule вызывается. (Для объяснения LoginModule флаги, требуемые, необходимые, достаточные и дополнительные, пожалуйста консультируйтесь javax.security.auth.login.Configuration документация и Приложение B: Конфигурационные файлы Входа в систему в Справочнике JAAS.) commit метод для a LoginModule проверяет его конфиденциально сохраненное состояние, чтобы видеть если его собственная аутентификация, за которой следуют. Если полное LoginContext аутентификация успешно выполнялась и LoginModule's собственная аутентификация успешно выполнялся, тогда commit метод связывает соответствующее Principals (аутентифицируемые идентификационные данные) и учетные данные (данные аутентификации, такие как криптографические ключи) с Subject.

Если LoginContext's полная отказавшая аутентификация (соответствующее, ТРЕБУЕМОЕ, НЕОБХОДИМОЕ, ДОСТАТОЧНОЕ и ДОПОЛНИТЕЛЬНОЕ LoginModules' login методы не успешно выполнялись), тогда abort метод для каждого LoginModule вызывается. В этом случае, LoginModule удаляет/уничтожает любое состояние аутентификации, первоначально сохраненное.

Выход из системы a Subject включает только одну фазу. LoginContext вызывает LoginModule's logout метод. logout метод для LoginModule тогда выполняет процедуры выхода из системы, такие как удаление Principals или учетные данные от Subject, или журналирование информации о сеансе.

Шаги, чтобы Реализовать a `LoginModule`

Шаги, требуемые, чтобы реализовать и протестировать a LoginModule следующее:

Шаг 1: Поймите Технологию Аутентификации

Шаг 2: Назовите LoginModule Реализация

Шаг 3: Реализуйте Краткий обзор LoginModule Методы

Шаг 4: Выберите или Запись Пример приложения

Шаг 5: Скомпилируйте LoginModule и Приложение

Шаг 6: Подготовьтесь к Тестированию

Шаг 6a: Поместите Ваш LoginModule и Код программы в Файлах JAR

Шаг 6b: Решите, Где Хранить Файлы JAR

Шаг 6c: Набор LoginModule и Полномочия Файла JAR Приложения

Шаг 6d: Создайте Конфигурацию, Ссылающуюся на LoginModule

Шаг 7: Тестовое Использование LoginModule

Шаг 8: Задокументируйте Ваш LoginModule Реализация

Шаг 9: Сделать LoginModule Файл JAR и Доступные Документы

Шаги, требуемые реализовать и протестировать новое LoginModule следовать. Пожалуйста, сошлитесь на SampleLoginModule и другие файлы, описанные в Справочнике JAAS для примеров того, что может быть сделано для различных шагов.

Шаг 1: Поймите Технологию Аутентификации

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

Одна вещь, которую Вы должны будете определить, состоит в том действительно ли Ваш LoginModule потребует некоторой формы взаимодействия с пользователем (получающий имя пользователя и пароль, например). Если так, Вы должны будете стать знакомыми с CallbackHandler взаимодействуйте через интерфейс и javax.security.auth.callback пакет. В том пакете Вы сочтете несколько возможными Callback реализации, чтобы использовать. (Альтернативно, можно создать свое собственное Callback реализации.) LoginModule вызовет CallbackHandler определенный приложением непосредственно и передал к LoginModule's initialize метод. LoginModule передачи CallbackHandler массив соответствующих Callbacks. См. метод входа в систему в Шаге 3.

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

Другая вещь, которую следует определить, состоит в том тем, какие параметры конфигурации Вы хотите сделать доступным для пользователя, который определяет конфигурационную информацию в любой форме, которую текущая реализация Конфигурации ожидает (например в файлах). Для каждой опции решите имя опции и возможные значения. Например, если a LoginModule может быть сконфигурирован, чтобы консультироваться с определенным узлом сервера аутентификации, выбрать ключевое имя опции ("auth_server", например), так же как возможные имена хоста сервера, допустимые для той опции ("server_one.example.com" и "server_two.example.com", например).

Шаг 2: Назовите `LoginModule` Реализация

Выберите надлежащий пакет и имя класса для Вашего LoginModule.

Например, a LoginModule разработанный IBM мог бы быть вызван com.ibm.auth.Module где com.ibm.auth имя пакета и Module имя LoginModule реализация класса.

Шаг 3: Реализуйте Краткий обзор `LoginModule` Методы

LoginModule интерфейс определяет пять абстрактных методов, которые требуют реализаций:

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

См. ниже и LoginModule API для получения дополнительной информации о каждом методе выше.

В дополнение к этим методам, a LoginModule реализация должна предоставить общедоступному конструктору без параметров. Это учитывает его надлежащее инстанцирование a LoginContext. Отметьте это, если никакому такому конструктору не предоставляют в Вашем LoginModule реализация, конструктор без параметров по умолчанию автоматически наследован от Object класс.

Метод LoginModule.initialize

public void initialize (
  Subject subject,
  CallbackHandler handler,
  Map<java.lang.String, ?> sharedState,
  Map<java.lang.String, ?> options) { ... }

initialize метод вызывают, чтобы инициализировать LoginModule с соответствующей аутентификацией и информацией о состоянии.

Этот метод вызывает a LoginContext сразу после этого LoginModule был инстанцирован, и до любых звонков в его другие открытые методы. Реализация метода должна хранить обеспеченные параметры за будущее использование.

initialize метод может дополнительно просмотреть обеспеченный sharedState, чтобы определить, какое дополнительное состояние аутентификации это было обеспечено другим LoginModules, и может также пересечь через предоставленные возможности, чтобы определить то, на что параметры конфигурации были определены, чтобы влиять LoginModule's поведение. Это может сохранить значения опции в переменных для будущего использования.

Отметьте: JAAS LoginModules может использовать опции, определенные в ПЭМ (use_first_pass, try_first_pass, use_mapped_pass, и try_mapped_pass) достигнуть единственного входа в систему. См. Службы Входа в систему Создания, Независимые от Authentication Technologies для дополнительной информации.

Ниже список опций, обычно поддерживаемых LoginModules. Отметьте, что следующее является просто инструкцией. Модули свободны поддерживать подмножество (или ни один) следующих опций.

try_first_pass - Если true, первый LoginModule в стеке сохраняет пароль, вводимые, и последующие LoginModules также пытаются использовать это. Если аутентификация перестала работать, подсказка LoginModules для нового пароля, и повторите аутентификацию.
use_first_pass - Если true, первый LoginModule в стеке сохраняет пароль, вводимые, и последующие LoginModules также пытаются использовать это. LoginModules не запрашивают новый пароль, если аутентификация перестала работать (аутентификация просто перестала работать).
try_mapped_pass - Если true, первый LoginModule в стеке сохраняет пароль, вводимые, и последующие LoginModules пытаются отобразить это в свой специфичный для службы пароль. Если аутентификация перестала работать, подсказка LoginModules для нового пароля, и повторите аутентификацию.
use_mapped_pass - Если true, первый LoginModule в стеке сохраняет пароль, вводимые, и последующие LoginModules пытаются отобразить это в свой специфичный для службы пароль. LoginModules не запрашивают новый пароль, если аутентификация перестала работать (аутентификация просто перестала работать).
moduleBanner - Если true, тогда, вызывая CallbackHandler, LoginModule предоставляет TextOutputCallback как первому Обратному вызову, который описывает LoginModule, выполняющий аутентификацию.
debug - Если true, дает LoginModule команду выводить отладочную информацию.

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

Отметьте что LoginContext вызов этого LoginModule (и другой сконфигурированный LoginModules, также), вся доля те же самые ссылки на обеспеченный Subject и sharedState. Модификации к Subject и sharedState будет, поэтому, замечен всеми.

Метод LoginModule.login

boolean login() throws LoginException;

login метод вызывают, чтобы аутентифицировать a Subject. Это - фаза 1 аутентификации.

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

Если Ваш LoginModule требует некоторой формы взаимодействия с пользователем (получающий имя пользователя и пароль, например), это не должно сделать так непосредственно. Это - то, потому что есть различные способы связаться с пользователем, и это является требуемым для LoginModules, чтобы остаться независимый от различных типов взаимодействия с пользователем. Скорее LoginModule's login метод должен вызвать handle метод CallbackHandler переданный к initialize метод, чтобы выполнить взаимодействие с пользователем и установить соответствующие результаты, такие как имя пользователя и пароль. LoginModule передачи CallbackHandler массив соответствующих Callbacks, например NameCallback для имени пользователя и PasswordCallback для пароля, и CallbackHandler выполняет требуемое взаимодействие с пользователем и устанавливает соответствующие значения в Callbacks. Например, чтобы обработать a NameCallback, CallbackHandler может запросить имя, получить значение от пользователя, и вызвать NameCallback's setName метод, чтобы сохранить имя.

Процесс аутентификации может также включить передачу по сети. Например, если бы эта реализация метода выполняет эквивалент kinit в Kerberos, то это должно было бы связаться с KDC. Если запись базы данных пароля находится в удаленной службе именования, то с той службой именования нужно связаться, возможно через Интерфейс Именования и Каталога Java (JNDI). Реализации могли бы также взаимодействовать с базовой операционной системой. Например, если пользователь уже зарегистрировал в операционную систему как Солярис или Windows NT, этот метод мог бы просто импортировать информацию об идентификационных данных базовой операционной системы.

login метод должен

Определите действительно ли это LoginModule должен быть проигнорирован. Один пример того, когда это должно быть проигнорировано, - то, когда пользователь пытается аутентифицировать под идентификационными данными, не важными этому LoginModule (если пользователь пытается аутентифицировать как корень, используя NIS, например). Если это LoginModule должен быть проигнорирован, login должен возвратиться false. Иначе, это должно сделать следующее:
Вызовите CallbackHandler handle метод, если взаимодействие с пользователем требуется.
Выполните аутентификацию.
Сохраните результат аутентификации (успех или провал).
Если аутентификация успешно выполнялась, сохраните любую соответствующую информацию о состоянии, которая может быть необходима commit метод.
Возвратиться true если аутентификация успешно выполняется, или бросок a LoginException такой как FailedLoginException если аутентификация перестала работать.

Отметьте что login реализация метода не должна связать никого нового Principal или информация об учетных данных с сохраненным Subject объект. Этот метод просто выполняет аутентификацию, и затем хранит результат аутентификации и соответствующее состояние аутентификации. К этому результату и состоянию позже получат доступ commit или abort метод. Отметьте, что результат и состояние не должны обычно сохраняться в sharedState Map, поскольку они не предназначаются, чтобы быть совместно использованными с другим LoginModules.

Пример того, где этот метод мог бы счесть полезным хранить информацию состояния в sharedState Map то, когда LoginModules конфигурируются, чтобы совместно использовать пароли. В этом случае введенный пароль был бы сохранен как общее состояние. Совместно используя пароли, пользователь только вводит пароль однажды, и может все еще аутентифицироваться к многократному LoginModules. Стандартные соглашения для сохранения и получения имен и паролей от sharedState Map следующее:

javax.security.auth.login.name - Используйте это в качестве ключа карты общего состояния для того, чтобы сохранить/получить имя.
javax.security.auth.login.password - Используйте это в качестве ключа карты общего состояния для того, чтобы сохранить/получить пароль.

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

Метод LoginModule.commit

boolean commit() throws LoginException;

commit метод вызывают, чтобы фиксировать процесс аутентификации. Это - фаза 2 аутентификации, когда фаза 1 успешно выполняется. Это вызывают если LoginContext's полная аутентификация, за которой следуют (то есть, если соответствующее, ТРЕБУЕМОЕ, НЕОБХОДИМОЕ, ДОСТАТОЧНОЕ и ДОПОЛНИТЕЛЬНОЕ LoginModules следовавший.)

Этот метод должен получить доступ к результату аутентификации и соответствующему состоянию аутентификации, сохраненному login метод.

Если результат аутентификации обозначает что login метод перестал работать, тогда это commit метод должен удалить/уничтожить любое соответствующее состояние, которое было первоначально сохранено.

Если сохраненный результат вместо этого обозначает что это LoginModule's login метод успешно выполнялся, тогда к соответствующей информации о состоянии нужно получить доступ, чтобы создать любого релевантного Principal и информация об учетных данных. Такой Principals и учетные данные должен тогда быть добавлен к Subject хранивший initialize метод.

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

commit метод должен сохранить частное состояние, указывающее ли фиксация, за которой следуют или отказавший.

Следующая диаграмма изображает что a LoginModule's commit метод должен возвратиться. Различные поля представляют различные ситуации, которые могут произойти. Например, верхнее левое угловое поле изображает что commit метод должен возвратиться если оба предыдущий звонок login следовавший и commit сам метод успешно выполнялся.

Возвращаемые значения метода LoginModule.commit
	ФИКСАЦИЯ: УСПЕХ	ФИКСАЦИЯ: ОТКАЗ
ВХОД В СИСТЕМУ: УСПЕХ	возвратите TRUE	выдайте ИСКЛЮЧЕНИЕ
ВХОД В СИСТЕМУ: ОТКАЗ	возвратите FALSE	возвратите FALSE

Метод LoginModule.abort

boolean abort() throws LoginException;

abort метод вызывают, чтобы прервать процесс аутентификации. Это - фаза 2 аутентификации, когда фаза 1 перестала работать. Это вызывают если LoginContext's полная аутентификация перестал работать.

Этот метод первые доступы это LoginModule's результат аутентификации и соответствующее состояние аутентификации, сохраненное login (и возможно commit) методы, и затем убирают и уничтожают информацию. Демонстрационное состояние, чтобы уничтожить было бы именами пользователей и паролями.

Если это LoginModule's попытка аутентификации перестал работать, тогда не должно быть никакого частного состояния, чтобы очистить.

Следующие диаграммы изображают что a LoginModule's abort метод должен возвратиться. Эта первая диаграмма предполагает что предыдущий звонок login следовавший. Например, верхнее левое угловое поле изображает что abort метод должен возвратиться если оба предыдущий звонок login и commit следовавший, и abort метод непосредственно также успешно выполнялся.

Возвращаемые значения метода LoginModule.abort; вход в систему успешно выполнялся
	АВАРИЙНОЕ ПРЕКРАЩЕНИЕ РАБОТЫ: УСПЕХ	АВАРИЙНОЕ ПРЕКРАЩЕНИЕ РАБОТЫ: ОТКАЗ
ФИКСАЦИЯ: УСПЕХ	возвратите TRUE	выдайте ИСКЛЮЧЕНИЕ
ФИКСАЦИЯ: ОТКАЗ	возвратите TRUE	выдайте ИСКЛЮЧЕНИЕ

Вторая диаграмма изображает что a LoginModule's abort метод должен возвратиться, предполагая что предыдущий звонок login отказавший. Например, верхнее левое угловое поле изображает что abort метод должен возвратиться если предыдущий звонок login отказавший, предыдущий звонок commit следовавший, и abort метод непосредственно также успешно выполнялся.

Возвращаемые значения метода LoginModule.abort; вход в систему перестал работать
	АВАРИЙНОЕ ПРЕКРАЩЕНИЕ РАБОТЫ: УСПЕХ	АВАРИЙНОЕ ПРЕКРАЩЕНИЕ РАБОТЫ: ОТКАЗ
ФИКСАЦИЯ: УСПЕХ	возвратите FALSE	возвратите FALSE
ФИКСАЦИЯ: ОТКАЗ	возвратите FALSE	возвратите FALSE

Метод LoginModule.logout

boolean logout() throws LoginException;

logout метод вызывают, чтобы выйти из системы a Subject.

Этот метод удаляет Principals, и удаляет/уничтожает учетные данные, связанные с Subject во время commit работа. Этот метод не должен коснуться тех Principals или учетные данные, ранее существующие в Subject, или добавленные другим LoginModules.

Если Subject был отмечен только для чтения ( Subject's isReadOnly метод возвращает true), тогда этот метод должен только уничтожить учетные данные, связанные с Subject во время commit работа (удаляющий учетные данные не возможно). Если Subject был отмечен как только для чтения и учетные данные, связанные с Subject во время commit работа не непрочна (они не реализуют Destroyable интерфейс), тогда этот метод может бросить a LoginException.

logout метод должен возвратиться true если выход из системы успешно выполняется, или иначе бросьте LoginException.

Шаг 4: Выберите или Запись Пример приложения

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

Шаг 5: Скомпилируйте `LoginModule` и Приложение

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

Шаг 6: Подготовьтесь к Тестированию

Шаг 6a: Поместите Ваш `LoginModule` и Код программы в Файлах JAR

Поместите Ваш LoginModule и код программы в отдельных файлах JAR, в подготовке к ссылке на файлы JAR в политике в Шаге 6c. Вот демонстрационная команда для того, чтобы создать файл JAR:

jar cvf <JAR file name> <list of classes, separated by spaces>

Эта команда создает файл JAR с указанным именем, содержащим указанные классы.

Для получения дополнительной информации по инструменту фляги см. флягу (для Соляриса) (для Microsoft Windows).

Шаг 6b: Решите, Где Хранить Файлы JAR

Приложение может быть сохранено по существу где угодно, Вам нравится.

Ваш LoginModule может также быть помещен куда угодно Вы (и другие клиенты) как. Если LoginModule полностью доверяется, это может быть помещено в JRE's lib/ext (стандартное расширение) каталог.

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

Если Ваш LoginModule помещается в JRE's lib/ext каталог, это будет обработано как установленное расширение, и никакие полномочия нельзя предоставить, так как системный файл политики по умолчанию предоставляет все полномочия установленным расширениям.

Если Ваш LoginModule помещается куда-либо еще, полномочия нужно предоставить, например grant операторы в файле политики.

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

Шаг 6c: Набор `LoginModule` и Полномочия Файла JAR Приложения

Если Ваш LoginModule и/или приложение выполняет чувствительные к безопасности задачи, которые инициируют проверки безопасности (делающий сетевые соединения, читая или пишущий файлы на локальном диске, и т.д.), нужно будет предоставить необходимые полномочия, если это не будет установленное расширение (см. Шаг 6b), и это выполняется, в то время как менеджер безопасности устанавливается.

С тех пор LoginModules обычно связываются Principals и учетные данные с аутентифицируемым Предметом, некоторыми типами полномочий a LoginModule будет обычно требовать AuthPermissions с целевыми именами "modifyPrincipals", "modifyPublicCredentials", и "modifyPrivateCredentials".

Демонстрационное предоставление оператора полномочия к a LoginModule чей код находится в MyLM.jar появляется ниже. Такой оператор мог появиться в файле политики. В этом примере, MyLM.jar файл, как предполагается, находится в /localWork каталог.

grant codeBase "file:/localWork/MyLM.jar" {
  permission javax.security.auth.AuthPermission "modifyPrincipals";
  permission javax.security.auth.AuthPermission "modifyPublicCredentials";
  permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
};

Отметьте: С тех пор a LoginModule всегда вызывается в пределах AccessController.doPrivileged вызовите, этому не придется вызвать doPrivileged непосредственно. Если это делает, это может непреднамеренно открыть дыру в системе безопасности. Например, a LoginModule это вызывает обеспеченный приложением CallbackHandler внутри a doPrivileged вызов открывает дыру в системе безопасности, разрешая приложение CallbackHandler чтобы получить доступ к ресурсам, это иначе не было бы в состоянии получить доступ.

Шаг 6d: Создайте Конфигурацию, Ссылающуюся на LoginModule

Поскольку JAAS поддерживает сменную архитектуру аутентификации, Ваше новое LoginModule может использоваться, не требуя модификаций к существующим приложениям. Только вход в систему Configuration потребности, которые будут обновлены, чтобы указать на использование нового LoginModule.

Значение по умолчанию Configuration реализация от Sun Microsystems читает конфигурационную информацию из конфигурационных файлов, как описано в com.sun.security.auth.login.ConfigFile.html.

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

    AppName {
        com.ibm.auth.Module REQUIRED debug=true;
    };

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

Шаг 7: Тестовое Использование `LoginModule`

Наконец, протестируйте свое приложение и его использование LoginModule. Когда Вы запускаете приложение, определите конфигурационный файл входа в систему, который будет использоваться. Например, предположите, что Ваше приложение называют MyApp, это располагается в MyApp.jar, и Ваш конфигурационный файл test.conf. Вы могли запустить приложение и определить конфигурационный файл через следующее:

java -classpath MyApp.jar
 -Djava.security.auth.login.config=test.conf MyApp

Введите все это на одной строке. Многократные строки используются здесь для четкости.

Определить названный файл политики my.policy и запущенный приложение с установленным менеджером безопасности, сделайте следующее:

java -classpath MyApp.jar -Djava.security.manager
 -Djava.security.policy=my.policy
 -Djava.security.auth.login.config=test.conf MyApp

Снова, введите все это на одной строке.

Можно хотеть сконфигурировать LoginModule с опцией отладки, чтобы помочь гарантировать, что это работает правильно.

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

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

Убедитесь, что также включали тестирование, используя различные опции инсталляции (например, делая LoginModule установленное расширение или размещение этого на пути к классу) и среды выполнения (с или без выполнения менеджера безопасности). Опции инсталляции обсуждаются в Шаге 6b. В частности чтобы гарантировать Ваш LoginModule работы, когда менеджер безопасности устанавливается и LoginModule и приложение не является установленными расширениями, Вы должны протестировать такую установку и среду выполнения, после предоставления необходимых полномочий, как описано в Шаге 6c.

Если Вы находите во время тестирования что Ваш LoginModule или приложение нуждается в модификациях, сделайте модификации, перекомпилируйте (Шаг 5), поместите обновленный код в файл JAR (Шаг 6a), переустановите файл JAR (Шаг 6b), если нужно фиксируйте или добавьте к полномочиям (Шаг 6c), если нужно измените конфигурационный файл входа в систему (Шаг 6d), и затем запустите повторно приложение и повторите эти шаги как необходимый.

Шаг 8: Задокументируйте Ваш `LoginModule` Реализация

Следующий шаг должен записать документацию для клиентов Вашего LoginModule. Документация в качестве примера, которую можно хотеть включать:

README или описание Руководства пользователя
- процесс аутентификации, используемый Вашим LoginModule реализация.
- информация о том, как установить LoginModule.
- параметры конфигурации, принятые LoginModule. Для каждой опции определите имя опции и возможные значения (или типы значений), так же как поведение средства управления опцией.
- полномочия, требуемые Вашим LoginModule когда это выполняется с менеджером безопасности (и это не установленное расширение).
Пример Configuration файл это ссылается на Ваше новое LoginModule.
Файл политики в качестве примера, предоставляющий Ваш LoginModule необходимые полномочия.
Документация API. Помещение javadoc комментирует в Ваш исходный код, поскольку Вы пишете, что это сделает API javadocs легким генерировать.

Шаг 9: Сделать `LoginModule` Файл JAR и Доступные Документы

Заключительный шаг должен сделать Ваш LoginModule Файл JAR и документация, доступная клиентам.

Свяжитесь с Нами