Пакет 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) в наборе частных учётных данных, в то время как некоторые другие механизмы могут искать в публичном наборе или в обоих. Если нужные учётные данные отсутствуют в соответствующих наборах текущего субъекта, вызов GSS-API должен завершиться ошибкой.

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

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

Документация по теме

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