Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Служба Аутентификации и авторизации Java (JAAS) была представлена как дополнительный пакет (расширение) Java 2 SDK, Standard Edition (J2SDK), v 1.3. JAAS был интегрирован в J2SDK 1.4.
JAAS может использоваться в двух целях:
JAAS реализует версию Java стандартного Сменного Модуля аутентификации (ПЭМ) платформа. См. для дополнительной информации.
Традиционно Java обеспечил codesource-на-основе средства управления доступом (средства управления доступом, основанные на том, где код, порожденный из и кто подписал код). Это испытывало недостаток, однако, в возможности дополнительно осуществить средства управления доступом, основанные на том, кто выполняет код. JAAS служит основой, которая увеличивает архитектуру безопасности Java с такой поддержкой.
Аутентификация JAAS выполняется сменным способом. Это разрешает приложениям оставаться независимыми от базовых технологий аутентификации. Новые или обновленные технологии аутентификации могут быть включены в соответствии с приложением, не требуя модификаций к приложению непосредственно. Приложения включают процессу аутентификации, инстанцируя a LoginContext объект, который поочередно ссылки a Configuration определить технологию (и) аутентификации, или LoginModule(s), чтобы использоваться в выполнении аутентификации. Типичный LoginModules может запросить и проверить имя пользователя и пароль. Другие могут считать и проверить выборка цифрового отпечатка или речь.
Однажды пользователь или служба, выполняющая код, аутентифицировался, компонентные работы авторизации JAAS в соединении с базовым Java модель управления доступом SE, чтобы защитить доступ к чувствительным ресурсам. В отличие от этого в J2SDK 1.3 и ранее, где решения управления доступом базируются исключительно на участке кода и кодируют подписывающие лица (a CodeSource), в J2SDK 1.4 решения управления доступом базируются оба на выполняющемся коде CodeSource и на пользователе или службе, выполняющей код, кто представляется a Subject объект. Subject обновляется a LoginModule с соответствующим Principals и учетные данные, если аутентификация успешно выполняется.
Этот документ предназначается для опытных разработчиков, которые требуют возможности разработать приложения, ограниченные a CodeSourceНа основе и SubjectНа основе модель обеспечения безопасности. Это также предназначается, чтобы быть считанным разработчиками LoginModule (разработчики, реализующие технологию аутентификации) до чтения Руководства разработчика LoginModule JAAS.
Можно хотеть сначала считать Аутентификацию JAAS и учебные руководства по Авторизации JAAS, чтобы получить краткий обзор того, как использовать JAAS и видеть пример кода в действии, и затем возвратиться к этому документу для дополнительной информации.
Этот документ предполагает, что Вы уже считали следующее:
Дополнение к этому руководству является Руководством разработчика LoginModule JAAS, предназначенным для опытных программистов, которые требуют возможности записать a LoginModule реализация технологии аутентификации.
Если Вы хотите узнать больше о стандартном Сменном Модуле аутентификации (ПЭМ) платформа (JAAS реализует версию Java ПЭМ), см. .
Следующие учебные руководства для аутентификации и авторизации JAAS могут быть выполнены всеми:
Подобные учебные руководства для аутентификации и авторизации JAAS, но которые демонстрируют использование Kerberos LoginModule и таким образом которые требуют установки Kerberos, могут быть найдены в
Эти два учебных руководства являются частью GSS-API Java и последовательностью JAAS учебных руководств, которые используют Kerberos как базовую технологию для аутентификации и защищают передачу.
Ключ JAAS class javax.security.auth.Subject, который представляет группировку соответствующей информации для единственного объекта, такого как человек. Это охватывает Принципалы объекта, общедоступные учетные данные, и частные учетные данные.
Отметьте что java.security.Principal интерфейс используется, чтобы представить Принципал. Также отметьте, что учетными данными, как определено JAAS, может быть любой Объект.
javax.security.auth.Subject заполняется со связанными идентификационными данными, или Principals. A Subject может иметь многих Principals. Например, у человека может быть имя Principal ("Джон Доу") и SSN Principal ("123-45-6789"), которые отличают это от других предметов. A Subject маю также принадлежат связанные с безопасностью атрибуты, которые упоминаются как учетные данные. Чувствительные учетные данные, которые требуют специальной защиты, такой как частные криптографические ключи, сохранены в пределах частных учетных данных Set. Учетные данные, предназначенные, чтобы быть совместно использованными, такие как сертификаты с открытым ключом, сохранены в пределах общедоступных учетных данных Set. Различные полномочия (описанный ниже) обязаны доступ и изменяют различные учетные данные Sets.
Предметы создаются, используя этих конструкторов:
public Subject();
public Subject(boolean readOnly, Set principals,
Set pubCredentials, Set privCredentials);
Первый конструктор создает a Subject с пустым (ненуль) Sets Principals и учетные данные. Второй конструктор создает a Subject с указанным Sets Principals и учетные данные. У этого также есть булев параметр, который может использоваться, чтобы сделать Subject только для чтения. В только для чтения Subject, Principal и учетные данные Sets являются неизменными. Писатель приложения не должен инстанцировать a Subject. Если приложение инстанцирует a LoginContext и не передает a Subject к LoginContext конструктор, LoginContext инстанцирует нового пустого Subject. См. раздел LoginContext.
Если a Subject не был инстанцирован, чтобы быть в состоянии только для чтения, оно может быть установлено только для чтения, вызывая следующий метод:
public void setReadOnly();
A javax.security.auth.AuthPermission с целью "setReadOnly" обязан вызывать этот метод. Однажды в состоянии только для чтения, любая попытка добавить или удалить Principals или учетные данные приведет к IllegalStateException быть брошенным. Следующий метод можно вызвать, чтобы протестировать a Subject's состояние только для чтения:
public boolean isReadOnly();
Получать Principals связанный с Предметом, два метода доступны:
public Set getPrincipals();
public Set getPrincipals(Class c);
Первый метод возвращает все Principals содержавшийся в Subject, в то время как второй метод только возвращает тех Principals, которые являются экземпляром указанного Класса c, или экземпляр подкласса Класса c. Пустое множество будет возвращено если Subject не имеет любой связался Principals.
Получать общедоступные учетные данные, связанные с a Subject, эти методы доступны:
public Set getPublicCredentials();
public Set getPublicCredentials(Class c);
Поведение этих методов подобно этому для getPrincipals методы, кроме в этом случае общедоступных учетных данных получаются.
Получить доступ к частным учетным данным, связанным с a Subject, следующие методы доступны:
public Set getPrivateCredentials();
public Set getPrivateCredentials(Class c);
Поведение этих методов подобно этому для getPrincipals и getPublicCredentials методы.
Изменить или работать на a Subject's Principal Set, общедоступные учетные данные Set, или частные учетные данные Set, вызывающие стороны используют методы, определенные в java.util.Set class. Следующий пример демонстрирует это:
Subject subject;
Principal principal;
Object credential;
. . .
// add a Principal and credential to the Subject
subject.getPrincipals().add(principal);
subject.getPublicCredentials().add(credential);
Отметьте: AuthPermission с целью "modifyPrincipals", "modifyPublicCredentials", или "modifyPrivateCredentials" обязан изменять соответствующее Sets. Также отметьте что только наборы, возвращенные через getPrincipals(), getPublicCredentials(), и getPrivateCredentials() методы без параметров поддерживаются Subject's соответствующие внутренние наборы. Поэтому любая модификация к возвращенному набору влияет на внутренние наборы также. Наборы, возвращенные через getPrincipals(Class c), getPublicCredentials(Class c), и getPrivateCredentials(Class c) методы не поддерживаются Subject's соответствующие внутренние наборы. Новый набор создается и возвращается для каждого такого вызова метода. Модификации к этим наборам не будут влиять Subject's внутренние наборы.
Чтобы выполнить итерации через ряд частных учетных данных, Вы нуждаетесь в a javax.security.auth.PrivateCredentialPermission получить доступ к каждым учетным данным. См.
PrivateCredentialPermission Документация API для дополнительной информации.
A Subject может быть связан с AccessControlContext (см. doAs и doAsPrivileged описания метода ниже). Следующий метод возвращается Subject связанный с указанным AccessControlContext, или null если нет Subject связывается с указанным AccessControlContext.
public static Subject getSubject(final AccessControlContext acc);
AuthPermission с целью "getSubject" обязан вызывать Subject.getSubject.
Subject class также включает следующие методы, наследованные от java.lang.Object.
public boolean equals(Object o);
public String toString();
public int hashCode();
Subject:
public static Object
doAs(final Subject subject,
final java.security.PrivilegedAction action);
public static Object
doAs(final Subject subject,
final java.security.PrivilegedExceptionAction action)
throws java.security.PrivilegedActionException;
Оба метода сначала связывают указанное subject с текущим потоком AccessControlContext, и затем выполнитесь action. Это достигает эффекта наличия action выполненный как subject. Первый метод может бросить исключения на этапе выполнения, но у нормального выполнения есть он возвращающий Объект из run метод action параметр. Второй метод ведет себя так же за исключением того, что он может выдать проверенное исключение от PrivilegedExceptionAction run метод. AuthPermission с целью "doAs" обязан вызывать doAs методы.
Вот пример, использующий первое doAs метод. Предположите, что кто-то названный "Бобом" аутентифицировался a LoginContext (см. раздел LoginContext), и в результате a Subject был заполнен с a Principal из class com.ibm.security.Principal, и это Principal имеет имя "БОБ". Также предположите, что SecurityManager был установлен, и что следующее существует в политике управления доступом (см. раздел Политики для большего количества деталей о файле политики).
// grant "BOB" permission to read the file "foo.txt"
grant Principal com.ibm.security.Principal "BOB" {
permission java.io.FilePermission "foo.txt", "read";
};
Вот код примера приложения:
class ExampleAction implements java.security.PrivilegedAction {
public Object run() {
java.io.File f = new java.io.File("foo.txt");
// the following call invokes a security check
if (f.exists()) {
System.out.println("File foo.txt exists");
}
return null;
}
}
public class Example1 {
public static void main(String[] args) {
// Authenticate the subject, "BOB".
// This process is described in the
// LoginContext section.
Subject bob;
// Set bob to the Subject created during the
// authentication process
// perform "ExampleAction" as "BOB"
Subject.doAs(bob, new ExampleAction());
}
}
Во время выполнения, ExampleAction встретится с проверкой защиты, когда она делает звонок f.exists(). Однако, с тех пор ExampleAction работает как "БОБ", и политика (выше) предоставляет необходимое FilePermission "КАЧАТЬСЯ", ExampleAction передаст проверку защиты. Если grant оператор в политике изменяется (добавление неправильного CodeBase или изменение Principal "МОУ", например), тогда a SecurityException будет брошен.
Следующие методы также выполняют действие как деталь Subject.
public static Object doAsPrivileged(
final Subject subject,
final java.security.PrivilegedAction action,
final java.security.AccessControlContext acc);
public static Object doAsPrivileged(
final Subject subject,
final java.security.PrivilegedExceptionAction action,
final java.security.AccessControlContext acc)
throws java.security.PrivilegedActionException;
AuthPermission с целью "doAsPrivileged" обязан вызывать doAsPrivileged методы.
doAsPrivileged методы ведут себя точно то же самое как doAs методы, за исключением того, что вместо того, чтобы связать обеспеченный Subject с текущим потоком AccessControlContext, они используют обеспеченный AccessControlContext. Таким образом действия могут быть ограничены AccessControlContexts отличающийся от текущего.
AccessControlContext содержит информацию обо всем коде, выполняемом начиная с AccessControlContext был инстанцирован, включая участок кода и полномочия, которые код предоставляет политика. Для проверки управления доступом, чтобы успешно выполниться, политика должна предоставить каждый элемент кода, на который ссылаются AccessControlContext необходимые полномочия.
Если AccessControlContext если к doAsPrivileged null, тогда действие не ограничивается отдельным AccessControlContext. Один пример, где это может быть полезно, находится в серверной среде. Сервер может аутентифицировать многократные входящие запросы и выполнить отдельное doAs работа для каждого запроса. Запустить каждого doAs "новое" действие, и без ограничений текущего сервера AccessControlContext, сервер может вызвать doAsPrivileged и передача в a null AccessControlContext.
Principals может быть связан с a Subject если аутентификация успешна. Principals представляют Subject идентификационные данные, и должны реализовать java.security.Principal и java.io.Serializable интерфейсы. Подчиненный раздел описывает способы обновить Principals связанный с a Subject.
Refreshable и Destroyable. javax.security.auth.Refreshable
интерфейс обеспечивает возможность учетных данных, чтобы обновить себя. Например, учетные данные с определенной ограниченной по времени продолжительностью жизни могут реализовать этот интерфейс, чтобы позволить вызывающим сторонам обновлять период времени, для которого это допустимо. У интерфейса есть два абстрактных метода:
boolean isCurrent();
Этот метод определяет, являются ли учетные данные текущими или допустимыми.
void refresh() throws RefreshFailedException;
Этот метод обновляет или расширяет законность учетных данных. Реализация метода должна выполнить AuthPermission("refreshCredential") у проверки защиты, чтобы гарантировать вызывающую сторону есть разрешение, чтобы обновить учетные данные. javax.security.auth.Destroyable
интерфейс обеспечивает возможность уничтожения содержания в пределах учетных данных. У интерфейса есть два абстрактных метода:
boolean isDestroyed();
Определяет, были ли учетные данные уничтожены.
void destroy() throws DestroyFailedException;
Уничтожает и очищает информацию, связанную с этими учетными данными. Последующие звонки в определенные методы на этих учетных данных приведут к IllegalStateException быть брошенным. Реализация метода должна выполнить AuthPermission("destroyCredential") у проверки защиты, чтобы гарантировать вызывающую сторону есть разрешение, чтобы уничтожить учетные данные. LoginContext.LoginContext консультируется с a Configuration загрузить весь из LoginModules сконфигурированный для того приложения.LoginContext's login метод.login метод вызывает все загруженные LoginModules. Каждый LoginModule попытки аутентифицировать предмет. На успех, LoginModules релевантный партнер Principals и учетные данные с a Subject объект, который представляет аутентифицируемый предмет.LoginContext возвращает состояние аутентификации приложению.Subject от LoginContext.Классы аутентификации описываются ниже.
javax.security.auth.login.LoginContext class обеспечивает основные методы, используемые, чтобы аутентифицировать предметы, и обеспечивает способ разработать не зависящую от приложения из базовой технологии аутентификации. LoginContext консультируется с a Configuration определить службы аутентификации, или LoginModule(s), сконфигурированный для определенного приложения. Поэтому, отличающийся LoginModules может быть включен в соответствии с приложением, не требуя никаких модификаций к приложению непосредственно.
LoginContext предложения четыре конструктора, из которых можно выбрать:
public LoginContext(String name) throws LoginException;
public LoginContext(String name, Subject subject) throws LoginException;
public LoginContext(String name, CallbackHandler callbackHandler)
throws LoginException
public LoginContext(String name, Subject subject,
CallbackHandler callbackHandler) throws LoginException
Все конструкторы совместно используют общий параметр: name. Этот параметр используется LoginContext как индексирование в Конфигурацию входа в систему, чтобы определить, который LoginModules конфигурируются для приложения, инстанцирующего LoginContext. Конструкторы, которые не берут a Subject как входной параметр инстанцируют нового Subject. Нулевые вводы отвергаются для всех конструкторов. Вызывающие стороны требуют AuthPermission с целью "createLoginContext. <имя>", чтобы инстанцировать a LoginContext. Здесь, <имя> обращается к имени записи конфигурации входа в систему что ссылки приложения в name параметр для LoginContext инстанцирование. См. раздел CallbackHandler для информации о какой a CallbackHandler и когда Вам, возможно, понадобится тот.
Фактическая аутентификация происходит со звонком в следующий метод:
public void login() throws LoginException;
Когда login вызывается, все сконфигурированные LoginModules вызываются, чтобы выполнить аутентификацию. Если аутентификация успешно выполнялась, Subject (который может теперь содержать Principals, общедоступные учетные данные, и частные учетные данные), может быть получен при использовании следующего метода:
public Subject getSubject();
К выходу из системы a Subject и удалите его аутентифицируемый Principals и учетные данные, следующий метод обеспечивается:
public void logout() throws LoginException;
Следующий пример кода демонстрирует вызовы, необходимые, чтобы аутентифицировать и выход из системы Предмет:
// let the LoginContext instantiate a new Subject
LoginContext lc = new LoginContext("entryFoo");
try {
// authenticate the Subject
lc.login();
System.out.println("authentication successful");
// get the authenticated Subject
Subject subject = lc.getSubject();
...
// all finished -- logout
lc.logout();
} catch (LoginException le) {
System.err.println("authentication unsuccessful: " +
le.getMessage());
}
LoginModule
интерфейс дает разработчикам возможность реализовать различные виды технологий аутентификации, которые могут быть включены в соответствии с приложением. Например, один тип LoginModule может выполнить форму username/password-based аутентификации. Другой LoginModules может взаимодействовать через интерфейс к устройствам, таким как смарт-карты или биометрические устройства.
Отметьте: Если Вы - писатель приложения, Вы не должны понять работы LoginModules. Все, что необходимо знать, - то, как записать Ваше приложение и определить конфигурационную информацию (такой как в конфигурационном файле входа в систему) так, что, приложение будет в состоянии использовать LoginModule, определенный конфигурацией, чтобы аутентифицировать пользователя.
Если с другой стороны Вы - программист, который хочет записать LoginModule, реализовывая технологию аутентификации, видеть JAAS LoginModule Руководство разработчика для подробных постепенных инструкций.
В некоторых случаях a LoginModule должен связаться с пользователем, чтобы получить информацию об аутентификации. LoginModules используют javax.security.auth.callback.CallbackHandler с этой целью. Приложения реализуют CallbackHandler
интерфейс и передача это к LoginContext, который вперед это непосредственно к базовому LoginModules. A LoginModule использование CallbackHandler оба, чтобы собрать ввод от пользователей (таких как пароль или смарт-карта прикрепляют число) или предоставлять информацию пользователям (таким как информация о статусе). Позволяя приложение определить CallbackHandler, базовый LoginModules может остаться независимым от различных способов, которыми приложения взаимодействуют с пользователями. Например, реализация a CallbackHandler для GUI приложение могло бы вывести на экран окно, чтобы требовать ввода от пользователя. С другой стороны, реализация a CallbackHandler для не-GUI инструмент мог бы просто запросить пользователя ввод непосредственно из командной строки.
CallbackHandler интерфейс с одним методом, чтобы реализовать:
void handle(Callback[] callbacks)
throws java.io.IOException, UnsupportedCallbackException;
LoginModule передачи CallbackHandler handle метод массив соответствующих Callbacks, например NameCallback для имени пользователя и PasswordCallback для пароля, и CallbackHandler выполняет требуемое взаимодействие с пользователем и устанавливает соответствующие значения в Callbacks. Например, чтобы обработать a NameCallback, CallbackHandler может запросить имя, получить значение от пользователя, и вызвать NameCallback's setName метод, чтобы сохранить имя.
CallbackHandler у документации есть длинный пример, не включенный в этот документ, который читатели могут хотеть исследовать.
Callback взаимодействуйте через интерфейс так же как несколько реализаций. LoginModules может передать массив Callbacks непосредственно к handle метод CallbackHandler.
Пожалуйста, консультируйтесь с различным Callback API для получения дополнительной информации об их использовании.
Чтобы заставить авторизацию JAAS иметь место, предоставляя полномочия управления доступом, базируемые не только на том, что код выполняет, но также и на том, кто выполняет это, следующее требуется:
Policy абстрактный class и специфичные для авторизации классы AuthPermission и PrivateCredentialPermission описываются ниже.
java.security.Policy class является абстрактный class для того, чтобы представить политику управления доступом в масштабе всей системы. Policy API был обновлен в J2SDK 1.4, чтобы поддерживать PrincipalНа основе запросы.
Как значение по умолчанию, J2SDK обеспечивает основанную на файле реализацию подкласса, которая была обновлена до поддержки PrincipalНа основе grant записи в файлах политики.
Файлы политики и структура записей в пределах них описываются в Синтаксисе Файла Реализации и Политики Политики Значения по умолчанию.
javax.security.auth.AuthPermission class инкапсулирует основные полномочия, требуемые для JAAS. AuthPermission содержит имя (также называемый "целевым именем"), но никакой список действий; у Вас или есть именованное разрешение, или Вы не делаете.
В дополнение к его наследованным методам (от java.security.Permission class), AuthPermission имеет двух общедоступных конструкторов:
public AuthPermission(String name);
public AuthPermission(String name, String actions);
Первый конструктор создает новое AuthPermission с указанным именем. Второй конструктор также создает новое AuthPermission объект с указанным именем, но имеет дополнительное actions параметр, который в настоящий момент неиспользован и должен быть нулем. Этот конструктор существует исключительно для Policy объект инстанцировать новый Permission объекты. Для большинства другого кода первый конструктор является соответствующим. В настоящий момент AuthPermission объект используется, чтобы охранять доступ к Policy, Subject, LoginContext, и Configuration объекты. Пожалуйста, обратитесь к AuthPermission javadocs для списка допустимых имен, которые поддерживаются.
javax.security.auth.PrivateCredentialPermission class защищает доступ к a Subject's частные учетные данные и предоставляет одному общедоступному конструктору:
public PrivateCredentialPermission(String name, String actions);
Пожалуйста, обратитесь к PrivateCredentialPermission javadocs для более подробной информации об этом class.
Аутентификация JAAS и учебные руководства по Авторизации JAAS содержат следующие выборки:
sample_jaas.config) как class, реализовывая требуемую базовую аутентификацию. Пользовательская аутентификация SampleLoginModule состоит из простой проверки, что у имени и пароля, определенного пользователем, есть определенные значения.Principal интерфейс. Это используется SampleLoginModule.См. учебные руководства для получения дальнейшей информации о приложениях, файлах политики, и конфигурационном файле входа в систему.
Писатели приложения не должны понять код для SampleLoginModule.java или SamplePrincipal.java, как объяснено в учебных руководствах. Программисты, которые хотят записать LoginModules, могут изучить, как сделать так, читая Руководство разработчика LoginModule JAAS.
Много настроек JAAS-related могут быть сконфигурированы в java.security основной файл свойств безопасности, который располагается в каталоге lib/безопасности Среды выполнения Java.
JAAS добавляет два новых свойства безопасности к java.security:
login.configuration.providerlogin.config.url.nСледующие существующие ранее свойства также важны для пользователей JAAS:
policy.providerpolicy.url.nЗначение по умолчанию реализация конфигурации входа в систему JAAS, обеспеченная Oracle, получает свою конфигурационную информацию от файлов и ожидает, что информация будет обеспечена в определенном формате, показанном в учебных руководствах.
Значение по умолчанию реализация конфигурации входа в систему JAAS может быть заменено, определяя альтернативного провайдера реализация class в login.configuration.provider свойство.
Например:
login.configuration.provider=com.foo.ConfigЕсли свойство Security
login.configuration.provider не находится, или оставляется неуказанным, тогда это устанавливается в значение по умолчанию: login.configuration.provider=com.sun.security.auth.login.ConfigFile
Отметьте, что нет никакого средства динамически установить провайдера конфигурации входа в систему из командной строки.
Если Вы используете реализацию конфигурации входа в систему, которая ожидает, что конфигурационная информация будет определена в файлах (как делает реализацию по умолчанию от Oracle), расположение конфигурационного файла (ов) входа в систему может быть статически установлено, определяя их соответствующие URL в login.config.url.n свойство. 'n' является последовательно пронумерованным целым числом, запускающимся с 1. Если многократные конфигурационные файлы определяются (если n> = 2), они будут считаны и unioned в одну единственную конфигурацию.
Например:
login.config.url.1=file:C:/config/.java.login.config login.config.url.2=file:C:/users/foo/.foo.login.config
Если расположение конфигурационных файлов не устанавливается в java.security файл свойств, и также не определяется динамически из командной строки (через -Djava.security.auth.login.config опция), JAAS пытается загрузить конфигурацию значения по умолчанию из
file:${user.home}/.java.login.config
Реализация политики значения по умолчанию может быть заменена, определяя альтернативного провайдера реализация class в policy.provider свойство.
Например:
policy.provider=com.foo.PolicyЕсли свойство Security
policy.provider не находится, или оставляется неуказанным, тогда Policy устанавливается в значение по умолчанию: policy.provider=sun.security.provider.PolicyFile
Отметьте, что нет никакого средства динамически установить провайдера политики из командной строки.
Расположение файлов политики управления доступом может быть статически установлено, определяя их соответствующие URL в auth.policy.url.n свойство. 'n' является последовательно пронумерованным целым числом, запускающимся с 1. Если многократные политики определяются (если n> = 2), они будут считаны и unioned в одну единственную политику.
Например:
policy.url.1=file:C:/policy/.java.policy policy.url.2=file:C:/users/foo/.foo.policy
Если расположение файла (ов) политики не устанавливается в java.security файл свойств, и не определяется динамически из командной строки (через -Djava.security.policy опция), значения по умолчанию политики управления доступом к той же самой политике, поскольку тот из системного файла политики устанавливается с J2SDK. Тот файл политики
Отметьте: Любые модификации к основному файлу свойств безопасности, $JAVA_HOME/jre/lib/java.security, может быть перезаписан последующими обновлениями JRE. Избегать такой перезаписи, альтернативы java.security файл свойств может быть определен от командной строки до системного свойства:
java.security.properties=<URL>
Этот файл свойств добавляет к основному файлу свойств безопасности. Если оба файла свойств определяют значения для того же самого ключа, значение от файла свойств командной строки выбирается, поскольку это - последний загруженный файл.
Кроме того, если Вы определяете java.security.properties==<URL>(2 знака "равно", а не 1 как в предыдущем примере), тогда что файл свойств полностью переопределяет основной файл свойств безопасности.
Конфигурации входа в систему располагаются, используя login.config.url.n свойства безопасности, найденные в java.security файл. Для получения дополнительной информации об этом свойстве и расположении java.security файл, см. Приложение A.
Реализация Конфигурации значения по умолчанию, ConfigFile, получает его конфигурационную информацию от конфигурационных файлов входа в систему. Для получения дополнительной информации о реализации Конфигурации входа в систему значения по умолчанию, предоставленной JAAS, пожалуйста, консультируйтесь с javadocs для
com.sun.security.auth.login.ConfigFile class.
Следующее является демонстрационным конфигурационным файлом входа в систему.
Login1 {
sample.SampleLoginModule required debug=true;
};
Login2 {
sample.SampleLoginModule required;
com.sun.security.auth.module.NTLoginModule sufficient;
com.foo.SmartCard requisite debug=true;
com.foo.Kerberos optional debug=true;
};
У приложения Login1 только есть тот сконфигурированный LoginModule, SampleLoginModule. Поэтому, попытка Login1, чтобы аутентифицировать предмет (пользователь или служба) будет успешна если и только если SampleLoginModule успешно выполняется.
Логику аутентификации для приложения Login2 легче объяснить с таблицей ниже. Отметьте: required, sufficient, requisite, и optional флаги описываются в Configuration javadocs.
| SampleLoginModule | необходимый | передача | передача | передача | передача | сбой | сбой | сбой | сбой |
| NTLoginModule | достаточный | передача | сбой | сбой | сбой | передача | сбой | сбой | сбой |
| SmartCard | необходимое | * | передача | передача | сбой | * | передача | передача | сбой |
| Kerberos | дополнительный | * | передача | сбой | * | * | передача | сбой | * |
| Полная Аутентификация | не применимый | передача | передача | передача | сбой | сбой | сбой | сбой | сбой |
