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