Пакет org.ietf.jgss

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

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

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

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

Получение учётных данных

GSS-API сам по себе не определяет, каким образом базовый механизм получает учётные данные, необходимые для аутентификации. Предполагается, что до вызова GSS-API эти учётные данные получены и сохранены в месте, известном поставщику механизма. Однако в платформе Java по умолчанию поставщики механизмов должны получать учётные данные только из закрытых или открытых наборов учётных данных, связанных с Subject в текущем контексте управления доступом. Механизм Kerberos v5 будет искать необходимые учётные данные INITIATE и ACCEPT (KerberosTicket и KerberosKey) в закрытом наборе учётных данных, тогда как некоторые другие механизмы могут искать их в открытом наборе или в обоих наборах. Если требуемые учётные данные отсутствуют в соответствующих наборах текущего Subject, вызов GSS-API должен завершиться ошибкой.

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

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

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

Онлайн-руководство по использованию Java GSS-API см. в разделе Введение в JAAS и Java GSS-API.