Пакет org.ietf.jgss

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

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

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

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

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

The 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.