См.: Описание
Интерфейс | Описание |
---|---|
GSSContext |
Этот интерфейс инкапсулирует контекст защиты GSS-API и предоставляет службам безопасности, которые доступны по контексту.
|
GSSCredential |
Этот интерфейс инкапсулирует учетные данные GSS-API для объекта.
|
GSSName |
Этот интерфейс инкапсулирует единственный объект принципала GSS-API.
|
Класс | Описание |
---|---|
ChannelBinding |
Этот class инкапсулирует понятие обеспеченной вызывающей стороной информации о привязке канала.
|
GSSManager |
Этот class служит фабрикой для других важных классов GSS-API и также предоставляет информацию о механизмах, которые поддерживаются.
|
MessageProp |
Это - утилита class, используемая в пределах методов GSSContext на сообщение, чтобы передать свойства на сообщение.
|
Oid |
Этот class представляет Универсальные Объектные Идентификаторы (Oids) и их связанные операции.
|
Исключение | Описание |
---|---|
GSSException |
Это исключение выдается всякий раз, когда ошибка GSS-API происходит, включая любой механизм определенная ошибка.
|
GSS-API определяется независимым от языка способом в
Приложение начинается, инстанцируя a GSSManager
который тогда служит фабрикой для контекста защиты. Приложение может использовать определенные основные имена и учетные данные, которые также создаются, используя GSSManager; или это может инстанцировать контекста с системными значениями по умолчанию. Это тогда проходит через цикл установления контекста. Как только контекст устанавливается с коллегой, аутентификация полна. Защита данных, такая как целостность и конфиденциальность может тогда быть получена из этого контекста.
GSS-API не выполняет передачи с коллегой. Это просто производит маркеры, которые приложение должно так или иначе транспортировать к другому концу.
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 #####
Для дальнейшей ссылки API и документации разработчика, см. Java Документация SE. Та документация содержит более подробные, предназначенные разработчиком описания, с концептуальными краткими обзорами, определениями сроков, обходных решений, и рабочих примеров кода.
Авторское право © 1993, 2013, Oracle и/или его филиалы. Все права защищены.
Проект сборка-b92