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. Тот файл политики
Below is a modified copy of the java.security file
provided with the Java SE 6. Example settings for JAAS-related
properties are shown in bold. In this example, we leave the values
provided in the default java.security file for the
policy.provider, policy.url.n, and
login.configuration.provider properties. The default
java.security file also lists a value for the
login.config.url.n property, but it is
commented out. In the example below, it is not commented.
#
# This is the "master security properties file".
#
# In this file, various security properties are set for use by
# java.security classes. This is where users can statically register
# Cryptography Package Providers ("providers" for short). The term
# "provider" refers to a package or set of packages that supply a
# concrete implementation of a subset of the cryptography aspects of
# the Java Security API. A provider may, for example, implement one or
# more digital signature algorithms or message digest algorithms.
#
# Each provider must implement a subclass of the Provider class.
# To register a provider in this master security properties file,
# specify the Provider subclass name and priority in the format
#
# security.provider.<n>=<className>
#
# This declares a provider, and specifies its preference
# order <n>. The preference order is the order in which providers are
# searched for requested algorithms (when no specific provider is
# requested). The order is 1-based; 1 is the most preferred, followed
# by 2, and so on.
#
# <className> must specify the subclass of the Provider class whose
# constructor sets the values of various properties that are required
# for the Java Security API to look up the algorithms or other
# facilities implemented by the provider.
#
# There must be at least one provider specification in java.security.
# There is a default provider that comes standard with the JDK. It
# is called the "SUN" provider, and its Provider subclass
# named Sun appears in the sun.security.provider package. Thus, the
# "SUN" provider is registered via the following:
#
# security.provider.1=sun.security.provider.Sun
#
# (The number 1 is used for the default provider.)
#
# Note: Statically registered Provider subclasses are instantiated
# when the system is initialized. Providers can be dynamically
# registered instead by calls to either the addProvider or
# insertProviderAt method in the Security class.
#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.provider.Sun
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=com.sun.rsajca.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
#
# Select the source of seed data for SecureRandom. By default it uses
# a system/thread activity algorithm. Optionally, if the platform supports
# it an entropy gathering device can be selected.
#
#securerandom.source=file:/dev/random
#
# The entropy gathering device is described as a URL and can
# also be specified with the property "java.security.egd". For example,
# -Djava.security.egd=file:/dev/urandom
# Specifying this property will override the securerandom.source setting.
#
# Class to instantiate as the javax.security.auth.login.Configuration
# provider.
#
login.configuration.provider=com.sun.security.auth.login.ConfigFile
#
# Default login configuration file
#
login.config.url.1=file:${user.home}/.java.login.config
#
# Class to instantiate as the system Policy. This is the name of the class
# that will be used as the Policy object.
#
policy.provider=sun.security.provider.PolicyFile
# The default is to have a single system-wide policy file,
# and a policy file in the user's home directory.
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
# whether or not we expand properties in the policy file
# if this is set to false, properties (${...}) will not be expanded in policy
# files.
policy.expandProperties=true
# whether or not we allow an extra policy to be passed on the command line
# with -Djava.security.policy=somefile. Comment out this line to disable
# this feature.
policy.allowSystemProperty=true
# whether or not we look into the IdentityScope for trusted Identities
# when encountering a 1.1 signed JAR file. If the identity is found
# and is trusted, we grant it AllPermission.
policy.ignoreIdentityScope=false
#
# Default keystore type.
#
keystore.type=jks
#
# Class to instantiate as the system scope:
#
system.scope=sun.security.provider.IdentityDatabase
#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageAccess unless the
# corresponding RuntimePermission ("accessClassInPackage."+package) has
# been granted.
package.access=sun.
#
# List of comma-separated packages that start with or equal this string
# will cause a security exception to be thrown when
# passed to checkPackageDefinition unless the
# corresponding RuntimePermission ("defineClassInPackage."+package) has
# been granted.
#
# by default, no packages are restricted for definition, and none of
# the class loaders supplied with the JDK call checkPackageDefinition.
#
#package.definition=
#
# Determines whether this properties file can be appended to
# or overridden on the command line via -Djava.security.properties
#
security.overridePropertiesFile=true
#
# Determines the default key and trust manager factory algorithms for
# the javax.net.ssl package.
#
ssl.KeyManagerFactory.algorithm=SunX509
ssl.TrustManagerFactory.algorithm=SunX509
#
# Determines the default SSLSocketFactory and SSLServerSocketFactory
# provider implementations for the javax.net.ssl package. If, due to
# export and/or import regulations, the providers are not allowed to be
# replaced, changing these values will produce non-functional
# SocketFactory or ServerSocketFactory implementations.
#
#ssl.SocketFactory.provider=
#ssl.ServerSocketFactory.provider=
-->
Отметьте: Любые модификации к основному файлу свойств безопасности, $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 | дополнительный | * | передача | сбой | * | * | передача | сбой | * |
| Полная Аутентификация | не применимый | передача | передача | передача | сбой | сбой | сбой | сбой | сбой |
