Пакет 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.