спецификации, руководства, описания, API

Java Универсальные Службы безопасности: (Java GSS) и Kerberos

Дополнительные функции, добавленные к Java

Эта страница описывает и перечисляет средства защиты и улучшения, добавленные к Java номером основной версии от v1.4 до v6.

ОТМЕТЬТЕ: API и функции, описанные в этом документе, подвержены изменениям.

Java Универсальные Службы безопасности (Java GSS) и Улучшения Kerberos для Java SE 6

Следующие улучшения были добавлены к Java реализация GSS/Kerberos в Java SE 6.

Поддержка типа шифрования AES

J2SE 5.0 поддерживает DES и Тройной тип шифрования DES со следующими псевдонимами:

des-cbc-md5 des-cbc-crc des3-cbc-sha1 Запускаясь с Java SE 6, поддержка типа шифрования AES (AES128 и AES256) в Java GSS/Kerberos доступен. Это улучшает функциональную совместимость Java SE реализация Kerberos с другими реализациями Kerberos, такими как Солярис 10 и MIT Kerberos.

Тип шифрования AES определяется в конфигурационном файле Kerberos под libdefaults раздел. Это определяется следующим образом со следующими тегами: default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes.

(Тип шифрования AES128)

aes128-cts aes128-cts-hmac-sha1-96 (Тип шифрования AES256)

aes256-cts aes256-cts-hmac-sha1-96 ОТМЕТЬТЕ: платформа JCE в пределах JDK включает возможность осуществить ограничения относительно криптографических алгоритмов и максимальных криптографических сильных мест, доступных приложениям. Такие ограничения определяются в "файлах политики юрисдикции". Файлы политики юрисдикции, связанные в Java SE, ограничивают максимальную длину ключа. Следовательно, чтобы использовать тип шифрования AES256, Вы должны будете установить JCE crypto политика с неограниченной версией, чтобы позволить AES с 256-разрядным ключом.

Например, libdefaults раздел в конфигурационном файле мог бы включать следующий.

default_tkt_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc permitted_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tkt_enctypes используется, чтобы определить типы шифрования, чтобы использовать для сеансового ключа в билете выдачи билетов. Это используется клиентом, чтобы ограничить типы шифрования сеансовых ключей, которые будут использоваться, чтобы связаться с KDC. Значение по умолчанию des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts .

default_tgs_enctypes используется, чтобы определить типы шифрования, чтобы использовать для сеансового ключа в обслуживании билеты. Это используется клиентом, чтобы ограничить типы шифрования сеансовых ключей, которые совместно используются клиентом и сервером. Значение по умолчанию des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts.

permitted_enctypes используется, чтобы определить типы шифрования, разрешенные использоваться службой. Это используется сервером, чтобы ограничить типы шифрования сеансовых ключей, которые это примет. Значение по умолчанию des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts.
Поддержка типа шифрования RC4-HMAC

J2SE 5.0 уже поддерживает DES и Тройной тип шифрования DES со следующими псевдонимами:
des-cbc-md5 des-cbc-crc des3-cbc-sha1 Запуск с Java, SE 6, поддержка шифрования RC4-HMAC вводит Java, GSS/Kerberos доступен. Это улучшает функциональную совместимость Java SE реализация Kerberos с другими реализациями Kerberos, такими как Windows, Солярис 10 и MIT Kerberos. Windows Активный Directoiory поддерживает RC4-HMAC как тип шифрования Kerberos по умолчанию.

Тип шифрования RC4-HMAC определяется в конфигурационном файле Kerberos под libdefaults раздел. Это определяется следующим образом со следующими тегами: default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes.

rc4-hmac arcfour-hmac arcfour-hmac-md5 Например, раздел libdefaults в конфигурационном файле мог бы включать следующий.

default_tkt_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc permitted_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tkt_enctypes используется, чтобы определить типы шифрования, чтобы использовать для сеансового ключа в билете выдачи билетов. Это используется клиентом, чтобы ограничить типы шифрования сеансовых ключей, которые будут использоваться, чтобы связаться с KDC. Значение по умолчанию des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts

default_tgs_enctypes используется, чтобы определить типы шифрования, чтобы использовать для сеансового ключа в обслуживании билеты. Это используется клиентом, чтобы ограничить типы шифрования сеансовых ключей, которые совместно используются клиентом и сервером. Значение по умолчанию des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts.

permitted_enctypes используется, чтобы определить типы шифрования, разрешенные использоваться службой. Это используется сервером, чтобы ограничить типы шифрования сеансовых ключей, которые это примет. Значение по умолчанию des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts.
Поддержка SPNEGO в Java GSS

Java SE теперь поддерживает механизм SPNEGO в Java GSS.

GSS Java является платформой, которая может поддерживать многократные механизмы безопасности; однако GSS-API не предписывает метод, которым коллеги GSS-API могут установить, есть ли у них механизм коллективной безопасности. Простое и Защищенное Согласование GSS-API (SPNEGO), механизм является псевдо механизмом безопасности, который позволяет коллегам GSS-API надежно согласовать механизм коллективной безопасности, который будет использоваться. Протокол SPNEGO используется, чтобы согласовать, какой механизм безопасности должен быть принят.

В настоящий момент Java приложения GSS определяет уникальный объектный идентификатор (OID), чтобы выбрать базовый механизм безопасности. Для например, Java приложения GSS определяют механизм Kerberos OID "1.2.840.113554.1.2.2 использовать механизм Kerberos. Oid mechOid = new Oid("1.2.840.113554.1.2.2");

Чтобы выбрать механизм безопасности SPNEGO, Java, приложения GSS должны были бы определить механизм SPNEGO OID "1.3.6.1.5.5.2". Oid mechOid = new Oid("1.3.6.1.5.5.2);

Поддержка SPNEGO улучшает функциональную совместимость с продуктами Microsoft. Протокол SPNEGO в большой степени используется, чтобы взаимодействовать с сервером Microsoft по HTTP, поддерживать основанную на HTTP Межплатформенную Аутентификацию через Согласовывать Протокол. Java SE теперь поддерживает схему аутентификации SPNEGO в HTTP также. Пожалуйста, контрольный список новых сетевых функций Java SE 6.
Поддержка новых Предварительных механизмов аутентификации

Java SE теперь включает поддержку новых предварительных механизмов аутентификации.

Kerberos является протоколом для того, чтобы проверить идентификационные данные принципалов. Протокол Kerberos обеспечивает механизм, названный предварительной аутентификацией для того, чтобы удостоверить личность принципала и для лучшей защиты долгосрочного секрета принципала.

Спецификация Kerberos определяет платформу для предварительных механизмов аутентификации Kerberos. Спецификация Kerberos Lastest определяет новые предварительные механизмы аутентификации, чтобы уведомить клиент, которые манипулируют, чтобы использовать, солят обновления, и другие дополнительные параметры. Новые предварительные механизмы аутентификации указывают на требование для дополнительной предварительной аутентификации.

С поддержкой новых предварительных механизмов аутентификации Java клиент GSS/Kerberos может теперь обработать соленые обновления значения когда требующийся.
Собственная платформа интеграция GSS

Эта функция позволяет приложениям Java использовать в своих интересах функции в собственной реализации GSS, доступной на платформе. Чтобы позволить Java GSS делегировать к собственной библиотеке GSS и ее списку собственных механизмов, установите системное свойство "sun.security.jgss.native" в истину. Когда включено, Java GSS искал бы собственную библиотеку GSS, используя собственное имя операционной системы, например, Солярис: libgss.so по сравнению с Linux: libgssapi.so. Если требуемая библиотека GSS имеет другое имя или не располагается в соответствии с каталогом для системных библиотек, то его полный путь должен быть определен, используя системное свойство "sun.security.jgss.lib".

Для Java SE 6, собственная поддержка GSS ограничивается Солярисом и Linux. Установка этих системных свойств на платформах, какая собственная интеграция GSS не поддерживается, будет проигнорирована.

В отличие от Java по умолчанию реализация GSS, которая полагается на KerberosLoginModule JAAS для начального учетного сбора, при использовании собственного GSS, начальные учетные данные, должна быть получена заранее, например, kinit, до вызова API JGSS.

Кроме того, выполняя операции как конкретная тема, например. Subject.doAs (...) или Subject.doAsPrivileged (...), будущим образом используемый GSSCredential должен быть добавлен к частному учетному набору Предмета. Иначе, операции GSS перестанут работать, так как никакие учетные данные не находятся.
Изменения Имен Записи Входа в систему JAAS

Имена записи входа в систему JAAS и для SunJSSE и для JGSS объединяются, и могут быть определены отдельно для различных механизмов. Для Kerberos 5, имена
```
com.sun.security.jgss.krb5.initiate
com.sun.security.jgss.krb5.accept
```

Java Универсальные Службы безопасности (Java GSS) и Улучшения Kerberos для J2SE 5.0

Следующие улучшения были добавлены к Java реализация GSS/Kerberos в J2SE 5.0.

Поддержка Тройного типа шифрования DES.
До J2SE 5.0, только поддерживался тип шифрования DES. J2SE 5.0 поддерживает и DES и Тройной тип шифрования DES. Это улучшает функциональную совместимость Java SE реализация Kerberos с другими реализациями Kerberos, такими как Солярис 10 и MIT Kerberos.
Тройной тип шифрования DES определяется в конфигурационном файле Kerberos под разделом "libdefaults". Это определяется как "des3-cbc-sha1" со следующими тегами: default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes. "у dec3-cbc-sha1" есть следующие псевдонимы:
```
des3-hmac-sha1
des3-cbc-sha1-kd
des3-cbc-hmac-sha1-kd
```
Например, раздел libdefaults в конфигурационном файле мог бы включать следующий.
```
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes   = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
```
default_tkt_enctypes используется, чтобы определить типы шифрования, чтобы использовать для сеансового ключа в билете выдачи билетов. Это используется клиентом, чтобы ограничить типы шифрования сеансовых ключей, которые будут использоваться, чтобы связаться с KDC. Значением по умолчанию является "des-cbc-md5 des-cbc-crc des3-cbc-sha1"
default_tgs_enctypes используется, чтобы определить типы шифрования, чтобы использовать для сеансового ключа в обслуживании билеты. Это используется клиентом, чтобы ограничить типы шифрования сеансовых ключей, которые совместно используются клиентом и сервером. Значением по умолчанию является "des-cbc-md5 des-cbc-crc des3-cbc-sha1".

permitted_enctypes используется, чтобы определить типы шифрования, разрешенные использоваться службой. Это используется сервером, чтобы ограничить типы шифрования сеансовых ключей, которые это примет. Значением по умолчанию является "des-cbc-md5 des-cbc-crc des3-cbc-sha1".
TCP по сравнению с Привилегированной Конфигурацией UDP
Java SE теперь поддерживает использование свойства "udp_preference_limit" в конфигурационном файле Kerberos (krb5.conf).
Отправляя сообщение KDC, Java SE библиотека Kerberos будет использовать TCP, если размер сообщения будет выше udp_preference_list. Если сообщение будет меньшим чем udp_preference_list, то UDP попробуют самое большее три раза. Если KDC укажет, что запрос является слишком большим, Java SE, то библиотека Kerberos будет использовать TCP.
Поддержка IPv6 в Kerberos
Java SE теперь поддерживает адреса IPv6 в билетах Kerberos. До J2SE 5, только адреса IPv4 поддерживались в билетах.
Возобновления TGT
Аутентификация Java и Сервер Authorizaton (JAAS) модуль входа в систему Kerberos в JDK 5.0, Krb5LoginModule, теперь поддерживают Билет Выдачи билетов (TGT) возобновление. Это позволяет продолжительным службам возобновлять свой TGT автоматически без взаимодействия с пользователем или требования, чтобы службы перезапустили.
С этой функцией, если Krb5LoginModule получает билет с истекшим сроком из кэша билета, TGT будет автоматически возобновлен и добавлен к Предмету вызывающей стороны, кто запрашивал билет. Если билет не может быть возобновлен ни по какой причине, то Krb5LoginModule будет использовать свой сконфигурированный обработчик обратного вызова, чтобы получить имя пользователя и пароль, чтобы получить новый TGT.

Чтобы использовать эту функцию, сконфигурируйте Krb5LoginModule, чтобы использовать кэш билета и установить недавно представленную опцию renewTGT в true. Вот пример конфигурационного файла входа в систему JAAS, который запрашивает возобновление TGT.
```
server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal=principal@your_realm
        useTicketCache=true
        renewTGT=true;
};
```
Отметьте что, если renewTGT устанавливается в истину, то useTicketCache должен также быть установлен в истину; иначе, это приводит к ошибке конфигурации.
Имена Записи входа в систему для SunJSSE
В JDK 5.0, провайдер SunJSSE добавил поддержку комплектов шифра Kerberos, как описано в RFC 2712 и Новые функции и возможности в JSSE в J2SE 5.0 в Справочнике JSSE. Следующие имена индексов конфигурации входа в систему JAAS резервируются для этой функции.
```
com.sun.net.ssl.server
com.sun.net.ssl.client
```
Когда приложение JSSE будет использовать комплекты шифра Kerberos без явной программы JAAS, провайдер SunJSSE будет использовать эти имена индексов, чтобы найти и сконфигурировать модуль входа в систему JAAS, чтобы получить необходимые учетные данные Kerberos. Например, у такого приложения мог бы быть следующий конфигурационный файл JAAS.
```
 com.sun.net.ssl.server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal=service_principal@your_realm
        useKeyTab=true
        keyTab=keytab_name
        storeKey=true;
};
```
Если запись не будет найдена, значение по умолчанию, "то другое" имя индекса будет использоваться. Имя службы для TLS является "узлом". Например, у службы TLS, работающей на машине под названием "raven.example.com" в области под названием "KRBNT-OPERATIONS.EXAMPLE.COM", было бы имя принципала службы
```
host/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM
```
Нет никаких ограничений на клиент TLS; это может использовать любое допустимое имя принципала Kerberos.
Когда приложение JSSE использует комплекты шифра Kerberos с явной программой JAAS, оно может использовать любое имя индекса, включая тех упомянутых выше.

Новые Функции в Java GSS для Java 2 SDK, Standard Edition, v 1.4.2

Конфигурируемые Настройки Kerberos
Центр распределения ключей Kerberos (KDC) имя и настройки области обеспечивается в конфигурационном файле Kerberos или через системные свойства java.security.krb5.kdc и java.security.krb5.realm. В предыдущих выпусках только вступили бы в силу изменения к значениям конфигурации Kerberos, когда приложение было перезапущено.
В 1.4.2 выпусках платформы Java, новой булевой опции refreshKrb5Config может быть определен в записи для Krb5LoginModule в конфигурационном файле JAAS. Если эта опция устанавливается в true, значения конфигурации будут обновлены перед login метод Krb5LoginModule вызывается.
Поддержка Ведомого устройства Центр распределения ключей Kerberos
Kerberos позволяет использование ведомого KDCs так, чтобы, если основной KDC недоступен, ведомый KDCs ответил на пользовательские запросы. В более ранних выпусках Java SE реализация Sun Kerberos, который попробовали только сдался бы основной KDC и, если бы не было никакого ответа в пределах тайм-аута KDC по умолчанию, определенного в конфигурационном файле Kerberos, или 30 секунд, если никакой тайм-аут не был определен.
С этими 1.4.2 выпусками реализация Sun Kerberos повторит с ведомым KDC (), если они будут определены. Ведомый KDCs может быть определен в конфигурационном файле Kerberos или через список KDCs, разделенного двоеточием (:) в системном свойстве java.security.krb5.kdc.
TCP поддержки для Транспорта Центра распределения ключей Kerberos
Реализация Sun Kerberos реализует версию 5 Kerberos согласно RFC 1510 и использует транспорт UDP для запросов билета. Новый интернет-проект обновляет этот RFC. Одна из дополнительных функций требуется поддержка TCP как транспорт в дополнение к UDP. В результате в случаях, где билеты Kerberos превышают пакетный предел размера UDP, KDC возвратил бы код ошибки, указывающий, что запрос должен быть снова послан по TCP.
В текущих 1.4.2 выпусках реализация Sun Kerberos теперь поддерживает автоматическую нейтрализацию к TCP. Поэтому, если запрос билета Kerberos, используя сбои UDP и KDC возвращает код ошибки KRB_ERR_RESPONSE_TOO_BIG, TCP является автоматически транспортом по умолчанию.
Билет Службы Kerberos в Частных Учетных данных Предмета
Билет службы Kerberos теперь сохранен в частных учетных данных Предмета. Это изменение предоставляет доступ разработчиков приложений к билету службы так, чтобы это могло использоваться вне JGSS (например в собственных приложениях или для собственного использования). Кроме того, билет службы может теперь быть снова использован, если приложение пытается установить контекст защиты к той же самой службе снова. Билет службы должен быть допустимым для этого, чтобы быть допускающим повторное использование.
Ранее, при использовании Java Универсальные Службы безопасности (JGSS) по Kerberos V5, если useSubjectCredsOnly свойство было установлено в истину, Билет Выдачи билетов (TGT) был получен от Предмета и использовался, чтобы установить Контекст защиты GSS. Полученный билет службы не был сохранен в Предмете. Теперь билет службы также сохранен в Предмете если useSubjectCredsOnly истина.

Если бы клиентское приложение перерывает частные учетные данные Предмета, в предыдущих выпусках это нашло бы только TGT. С этого выпуска это также сочтет любой билет (ы) Службы полученным.

Отчет об ошибках, связанный с этим изменением, 4688866.

Свяжитесь с Нами