Пакет org.ietf.jgss

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

См.: Описание

Интерфейсная Сводка

Интерфейс	Описание
GSSContext	Этот интерфейс инкапсулирует контекст защиты GSS-API и предоставляет службам безопасности, которые доступны по контексту.
GSSCredential	Этот интерфейс инкапсулирует учетные данные GSS-API для объекта.
GSSName	Этот интерфейс инкапсулирует единственный объект принципала GSS-API.

Сводка класса

Класс	Описание
ChannelBinding	Этот класс инкапсулирует понятие обеспеченной вызывающей стороной информации о привязке канала.
GSSManager	Этот класс служит фабрикой для других важных классов GSS-API и также предоставляет информацию о механизмах, которые поддерживаются.
MessageProp	Это - служебный класс, используемый в пределах методов GSSContext на сообщение, чтобы передать свойства на сообщение.
Oid	Этот класс представляет Универсальные Объектные Идентификаторы (Oids) и их связанные операции.

Сводка исключения

Исключение	Описание
GSSException	Это исключение выдается всякий раз, когда ошибка GSS-API происходит, включая любой механизм определенная ошибка.

Пакет org.ietf.jgss Описание

Этот пакет представляет платформу, которая позволяет разработчикам приложений использовать службы безопасности как аутентификация, целостность данных и конфиденциальность данных от множества базовых механизмов безопасности как Kerberos, используя объединенный API. Механизмы безопасности, что приложение может, хотели использовать, идентифицируются с уникальными объектными идентификаторами. Одним примером такого механизма является Kerberos v5 механизм GSS-API (объектный идентификатор 1.2.840.113554.1.2.2). Этот механизм доступен через экземпляр по умолчанию класса GSSManager.

GSS-API определяется независимым от языка способом в RFC 2743. Привязки к языку Java определяются в RFC 2853

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

GSS-API не выполняет передачи с коллегой. Это просто производит маркеры, которые приложение должно так или иначе транспортировать к другому концу.

Учетный Сбор

Сам GSS-API не диктует, как базовый механизм получает учетные данные, которые необходимы для аутентификации. Предполагается, что до вызова GSS-API, эти учетные данные получаются и сохранены в расположении, о котором знает провайдер механизма. Однако, модель по умолчанию в платформе Java будет то, что провайдеры механизма должны получить учетные данные только из частных или общедоступных учетных наборов, связанных с Subject в текущем контексте управления доступом. Kerberos v5 механизм будет искать необходимого НОВИЧКА и ПРИНИМАТЬ учетные данные (KerberosTicket и KerberosKey) в частном учетном наборе, где, поскольку некоторый другой механизм мог бы смотреть в общедоступном наборе или в обоих. Если требуемые учетные данные не присутствуют в соответствующих наборах текущего Предмета, GSS-вызов-API должен перестать работать.

У этой модели есть преимущество, что учетное управление просто и предсказуемо с точки зрения приложений. Приложение, учитывая правильные полномочия, может произвести чистку учетных данных в Предмете или возобновить их использующий стандартный API Java. Если бы это произвело чистку учетных данных, то это убедилось бы, что механизм JGSS перестал бы работать, или если бы это возобновило время базируемые учетные данные, то это убедилось бы, что механизм JGSS успешно выполнился бы.

Эта модель действительно требует этого a JAAS login будьте выполнены, чтобы аутентифицировать и заполнить Предмет, который может позже использовать JGSS mechnanism. Однако, у приложений есть возможность ослабить это переприлипание посредством системного свойства: javax.security.auth.useSubjectCredsOnly. По умолчанию это системное свойство, как будет предполагаться, будет true (даже когда это сбрасывается), указание, что провайдеры должны только использовать учетные данные, которые присутствуют в текущем Предмете. Однако, если это свойство явно устанавливается в ложь приложением, то это указывает, что провайдер свободен использовать любой кэш учетных данных своего выбора. Такой учетный кэш мог бы быть дисковым кэшем, в кэш-памяти, или даже только текущий Предмет непосредственно.

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

Для онлайнового учебного руководства при использовании GSS-API Java, пожалуйста, см. Введение в GSS-API Java и JAAS.

##### FILL IN ANY SPECS NEEDED BY JAVA COMPATIBILITY KIT #####

• ##### REFER TO ANY FRAMEMAKER SPECIFICATION HERE #####

Related Documentation

For overviews, tutorials, examples, guides, and tool documentation, please see:

• ##### REFER TO NON-SPEC DOCUMENTATION HERE #####

-->

С тех пор:

1.4