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