Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации
СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT

7 GuardedObject и SignedObject


7.1 java.security. GuardedObject и java.security. Защита

Вспомните, что class, AccessControlContext полезен, когда решение управления доступом должно быть принято в различном контексте. Есть другой такой сценарий, где поставщик ресурса не находится в том же самом потоке как comsumer того ресурса, и потребительский поток не может обеспечить, поставщик распараллеливают контекстную информацию управления доступом (потому что контекст чувствителен к безопасности, или контекст является слишком большим, чтобы передать, или по другим причинам). Для этого случая мы обеспечиваем class по имени GuardedObject, чтобы защитить доступ к ресурсу, иллюстрированному в числе ниже.

Иллюстрация предыдущего контекста

Основная идея состоит в том, что поставщик ресурса может создать объект, представляющий ресурс, создать GuardedObject, который встраивает объект ресурса внутри, и затем предоставьте GuardedObject потребителю. В создании GuardedObject поставщик также определяет объект Защиты так, что, любой (включая потребителя) может только получить объект ресурса, если бесспорный (безопасность) проверки в Защите удовлетворяются.

Защита является интерфейсом, таким образом, любой объект может хотеть становиться Защитой. Единственный метод в этом интерфейсе вызывают checkGuard. Это берет Объектный параметр, и это выполняет бесспорный (безопасность) проверки. Разрешение class в java.security реализует интерфейс Защиты.

Например, предположите, что системный поток просят открыть файл /a/b/c.txt для доступа для чтения, но системный поток не знает, кто проситель или при каких обстоятельствах с просьбой обращаются. Поэтому, корректное решение управления доступом не может быть принято в стороне сервера. Системный поток может использовать GuardedObject, чтобы задержать проверку управления доступом, следующим образом.

FileInputStream f = new FileInputStream("/a/b/c.txt");
FilePermission p = new FilePermission("/a/b/c.txt", "read");
GuardedObject g = new GuardedObject(f, p);
Теперь системный поток может передать г к потребительскому потоку. Для того потока, чтобы получить входной поток файла, это должно вызвать
FileInputStream fis = (FileInputStream) g.getObject();
Этот метод поочередно вызывает checkGuard метод на Защите возражает p, и потому что p является Разрешение, checkGuard метод фактически:
SecurityManager sm = System.getSecurityManager();
if (sm != null) sm.checkPermission(this);
Это гарантирует, что надлежащая проверка управления доступом имеет место в пределах потребительского контекста. Фактически, можно заменить часто используемые хэш-таблицы и списки управления доступом во многих случаях и просто сохранить хэш-таблицу GuardedObjects.

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

Отметьте, что определенная информация о вводе теряется, потому что GuardedObject возвращает Объект. GuardedObject предназначается, чтобы использоваться между сотрудничающими сторонами так, чтобы принимающая сторона знала какой объект ожидать (и бросить для). Фактически, мы предполагаем это, большинство использования GuardedObject включает разделение на подклассы этого (скажите, чтобы сформировать GuardedFileInputStream class), таким образом инкапсулируя ввод информации, и бросок может произойти соответственно в подклассе.


7.2 java.security. SignedObject

Этот class является существенным стандартным блоком для других примитивов безопасности. SignedObject содержит другой Сериализуемый объект, (чтобы быть) подписанный объект и его подпись. Если подпись не является нулем, она содержит допустимую цифровую подпись подписанного объекта. Это иллюстрируется в числе ниже.

Предыдущий контекст описывает эту графику

Базовый алгоритм подписания устанавливается через объект Подписи в качестве параметра к sign вызов метода, и алгоритм могут быть, среди других, DSA стандарта NIST, используя DSA и SHA 1. Алгоритм определяется, используя то же самое соглашение для подписей, таких как "SHA/DSA".

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

Типичным примером создания подписанного объекта является следующее:

Signature signingEngine =
    Signature.getInstance(algorithm,provider);
SignedObject so =
    new SignedObject(myobject, signingKey, signingEngine);
Типичным примером проверки является следующий (получавший SignedObject so), где первая строка не необходима, если имя алгоритма известно:
String algorithm = so.getAlgorithm();
Signature verificationEngine =
    Signature.getInstance(algorithm, provider);
so.verify(verificationEngine);
Возможное применение SignedObject включает: Это предназначается, что этот class может быть разделен на подклассы в будущем, чтобы позволить многократные подписи на том же самом подписанном объекте. В этом случае существующие вызовы метода в этом основном class будут полностью совместимыми в семантике. В частности любой get метод возвратит уникальное значение, если будет только одна подпись, и возвратит произвольный из набора подписей, если есть больше чем одна подпись.

СОДЕРЖАНИЕ | ПРЕДЫДУЩИЙ | NEXT
Авторское право © 1997-1999 Sun Microsystems, Inc. Все права защищены.

Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами