Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

Java API SASL
Программирование и Руководство по Развертыванию


  1. Введение
  2. Краткий обзор API
  3. Как Механизмы SASL Устанавливаются и Выбираются
  4. Провайдер SunSASL
  5. Реализация Поставщика систем обеспечения безопасности SASL

Введение

Каков SASL?

Простой Уровень Аутентификации и Безопасности, или SASL, является интернет-стандартом (RFC 2222), который определяет протокол для аутентификации и дополнительного установления уровня безопасности между приложениями клиента и сервера. SASL определяет, как данные аутентификации должны быть переданы, но самостоятельно не определяют содержание тех данных. Это - платформа, в который определенные механизмы аутентификации, которые определяют содержание, и семантика данных аутентификации может соответствовать.

SASL используется протоколами, такими как Легкий Протокол Доступа Каталога, версия 3 (LDAP v3), и Интернет передает Протокол Доступа, версию 4 (IMAP v4), чтобы включить сменной аутентификации. Вместо того, чтобы соединить метод аутентификации проводами в протокол, LDAP v3 и IMAP v4 используют SASL, чтобы выполнить аутентификацию, таким образом включая аутентификации через различные механизмы SASL.

Есть много стандартных механизмов SASL, определенных интернет-сообществом для различных уровней сценариев развертывания и безопасности. Они не колеблются ни от какой безопасности (например, анонимная аутентификация) к высокой степени безопасности (например, аутентификация Kerberos) и уровни промежуточный.

Java API SASL

Java API SASL определяет классы и интерфейсы для приложений то использование механизмы SASL. Это определяется, чтобы быть нейтральным механизмом: приложение, которое использует API, не должно быть предрасположено в использование никакого определенного механизма SASL. API поддерживает оба приложения клиента и сервера. Это позволяет приложениям выбирать механизм, чтобы использовать основанный на требуемых средствах защиты, такой как, восприимчивы ли они к пассивным атакам с подбором по словарю или принимают ли они анонимную аутентификацию.

Java API SASL также позволяет разработчикам использовать свои собственные, пользовательские механизмы SASL. Механизмы SASL устанавливаются при использовании Архитектуры Криптографии Java (JCA).

Когда Использовать SASL

SASL обеспечивает сменную аутентификацию и уровень безопасности для сетевых приложений. Есть другие функции в Java SE, которые обеспечивают подобную функциональность, включая Расширение Защищенного сокета Java (JSSE), и Java Универсальная Служба безопасности (Java GSS). JSSE служит основой и реализацией для версии языка Java протоколов TLS и SSL. Java GSS является привязками к языку Java для Универсального Прикладного программного интерфейса Службы безопасности (GSS-API). Единственным механизмом, в настоящий момент поддерживаемым под этим API на Java SE, является Kerberos v5.

При сравнении с JSSE и Java GSS, SASL относительно легок и популярен среди более свежих протоколов. У этого также есть преимущество, что несколько популярные, легкие (в поддержке инфраструктуры сроков) механизмы SASL были определены. Основной JSSE и Java, у механизмов GSS, с другой стороны, есть относительно тяжелые механизмы, которые требуют более тщательно продуманных инфраструктур (Инфраструктура управления открытыми ключами и Kerberos, соответственно).

SASL, JSSE, и Java GSS часто используются вместе. Например, общий образец для приложения, чтобы использовать JSSE для того, чтобы установить безопасный канал, и использовать SASL для клиента, username/password-based аутентификация. Есть также механизмы SASL, многоуровневые сверху механизмов GSS-API; одним популярным примером является SASL GSS-API/Kerberos v5 механизм, который используется с LDAP.

Кроме тех случаев, когда определение и создание протоколов с нуля, часто самый большой фактор, определяющий, какой API использовать является определением протокола. Например, LDAP и IMAP определяются, чтобы использовать SASL, таким образом, программное обеспечение, связанное с этими протоколами, должно использовать Java API SASL. Создавая приложения Kerberos и службы, API, чтобы использовать является Java GSS. Создавая приложения и службы, которые используют SSL/TLS в качестве их протокола, API, чтобы использовать является JSSE. См. Документацию Безопасности Java для получения дальнейшей информации о том, когда использовать JSSE против Java GSS.

Краткий обзор API

SASL является протоколом ответа проблемы. Сервер выпускает вызов клиенту, и клиент отправляет ответ, основанный на проблеме. Этот обмен продолжается, пока сервер не удовлетворяется и не выпускает дальнейшей проблемы. Эти проблемы и ответы являются двоичными маркерами произвольной длины. Протокол инкапсуляции (такой как LDAP или IMAP) определяет, как эти маркеры кодируются и обмениваются. Например, LDAP определяет, как маркеры SASL инкапсулируются в пределах LDAP, связывают запросы и ответы.

Java API SASL моделируется согласно этому стилю взаимодействия и использования. У этого есть интерфейсы, SaslClient и SaslServer, которые представляют механизмы клиентской стороны и серверной стороны, соответственно. Приложение взаимодействует с механизмами через байтовые массивы, которые представляют проблемы и ответы. Механизм серверной стороны выполняет итерации, выпуская проблемы и обрабатывая ответы, пока он не удовлетворяется, в то время как механизм клиентской стороны выполняет итерации, оценивая проблемы и выпуская ответы, пока сервер не удовлетворяется. Приложение, которое использует механизм, управляет каждой итерацией. Таким образом, это извлекает проблему или ответ от пакета протокола и предоставляет это к механизму, и затем помещает ответ или проблему, возвращенную механизмом в пакет протокола, и отправляет это коллеге.

Создание Механизмов

Код клиента и сервера, который использует механизмы SASL, не предрасположен использовать определенный механизм (ы). Во многих протоколах, которые используют SASL, сервер рекламирует (или статически или динамически) список механизмов SASL, которые это поддерживает. Клиент тогда выбирает один из них основанных на его требованиях к защите.

Класс Sasl используется для того, чтобы создать экземпляры SaslClient и SaslServer. Вот пример того, как приложение создает клиентский механизм SASL, используя список возможных механизмов SASL.

String[] mechanisms = new String[]{"DIGEST-MD5", "PLAIN"}; 
SaslClient sc = Sasl.createSaslClient(mechanisms, authzid, protocol, 
                serverName, props, callbackHandler);

Основанный на доступности механизмов, поддерживаемых платформой и другой конфигурационной информацией, обеспеченной через параметры, Java, платформа SASL выбирает один из перечисленных механизмов, и возвратите экземпляр SaslClient.

Имя выбранного механизма обычно передается к серверу через протокол приложения. После получения имени механизма сервер создает соответствующий объект SaslServer обработать отправленный клиентом ответы. Вот пример того, как сервер создал бы экземпляр SaslServer.

SaslServer ss = Sasl.createSaslServer(mechanism, protocol, 
                  myName, props, callbackHandler);

Передача Ввода к Механизмам

Поскольку Java, API SASL является общими рамками, он должен быть в состоянии разместить много различных типов механизмов. Каждый механизм должен быть инициализирован с вводом и, возможно, должен ввести, чтобы сделать успехи. API обеспечивает три, подразумевает, который приложение дает вводу механизму.

  1. Общие входные параметры. Приложение использует предопределенные параметры, чтобы предоставить информацию, которые определяются спецификацией SASL и обычно требуются механизмами. Для клиентских механизмов SASL входные параметры являются идентификатором авторизации, идентификатором протокола, и именем сервера. Для механизмов сервера SASL общие входные параметры являются prototol идентификатором и (его полностью определенное собственное) имя сервера.
  2. Параметр свойств. Приложение использует параметр свойств, отображение имен свойства к (возможно нестрока) значения свойств, чтобы предоставить конфигурационную информацию. Java API SASL определяет некоторые стандартные свойства, такие как качество защиты, сила шифра, и максимальный размер буфера. Параметр может также использоваться, чтобы передать в нестандартных свойствах, которые являются определенными для определенных механизмов.
  3. Обратные вызовы. Приложение использует параметр обработчика обратного вызова, чтобы предоставить ввод, который не может быть предопределен или не мог бы быть распространен через механизмы. Когда механизм требует входных данных, он использует обработчик обратного вызова, предоставленный приложением, чтобы собрать данные, возможно от конечного пользователя приложения. Например, механизм мог бы потребовать, чтобы конечный пользователь приложения предоставил имя и пароль.

    Механизмы могут использовать обратные вызовы, определенные в пакете javax.security.auth.callback; они - универсальные обратные вызовы, полезные для того, чтобы создали приложения, которые выполняют аутентификацию. Механизмы, возможно, также нуждались бы в обратных вызовах SASL-specific, таких как те для того, чтобы собрать область и информацию об авторизации, или даже (нестандартизировали) специфичные для механизма обратные вызовы. Приложение должно быть в состоянии разместить множество механизмов. Следовательно, его обработчик обратного вызова должен быть в состоянии обслужить все обратные вызовы, которые могли бы запросить механизмы. Это не возможно вообще для произвольных механизмов, но обычно выполнимо из-за ограниченного количества механизмов, которые обычно развертываются и используются.

Используя Механизмы

Как только приложение создало механизм, оно использует механизм, чтобы получить маркеры SASL, чтобы обмениваться с коллегой. Клиент обычно указывает к серверу через протокол приложения который механизм использовать. Некоторые протоколы позволяют клиенту сопровождать запрос с дополнительным начальным ответом для механизмов, у которых есть начальный ответ. Эта функция может быть использована, чтобы понизить число обменов сообщениями, требуемых для аутентификации. Вот пример того, как клиент мог бы использовать SaslClient для аутентификации.
// Get optional initial response
byte[] response = 
    (sc.hasInitialResponse() ? sc.evaluateChallenge(new byte[]) : null);

String mechanism = sc.getName();

// Send selected mechanism name and optional initial response to server
send(mechanism, response);

// Read response
msg = receive();
while (!sc.isComplete() && (msg.status == CONTINUE || msg.status == SUCCESS)) {
    // Evaluate server challenge
    response = sc.evaluateChallenge(msg.contents);

    if (msg.status == SUCCESS) {
        // done; server doesn't expect any more SASL data
        if (response != null) {
           throw new IOException(
               "Protocol error: attempting to send response after completion");
        }
        break;
    } else {
        send(mechanism, response);
        msg = receive();
    }

Клиентское приложение выполняет итерации через каждый шаг аутентификации при использовании механизма (sc), чтобы оценить проблему, полученную от сервера и заставить ответ отсылать назад к серверу. Это продолжает этот цикл, пока или протокол механизма или уровня приложения не указывает, что аутентификация завершилась, или если механизм не может оценить проблему. Если механизм не может оценить проблему, он выдает исключение, чтобы указать на ошибку и завершает аутентификацию. Разногласие между механизмом и протоколом о состоянии завершения должно быть обработано как ошибка, потому что это могло бы указать на компромисс обмена аутентификации.

Вот пример того, как сервер мог бы использовать SaslServer.

// Read request that contains mechanism name and optional initial response
msg.receive();

// Obtain a SaslServer to perform authentication
SaslServer ss = Sasl.createSaslServer(msg.mechanism, 
    protocol, myName, props, callbackHandler);

// Perform authentication steps until done
while (!ss.isComplete()) {
    try {
        // Process response
        byte[] challenge = sc.evaluateResponse(msg.contents);

        if (ss.isComplete()) {
            send(mechanism, challenge, SUCCESS);
        } else {
            send(mechanism, challenge, CONTINUE);
            msg.receive();
        }
    } catch (SaslException e) {
        send(ERROR);
        sc.dispose();
        break;
    }
}
Серверное приложение выполняет итерации через каждый шаг аутентификации, давая ответ клиента на механизм (ss), чтобы обработать. Если ответ является неправильным, механизм указывает на ошибку, бросая SaslException так, чтобы сервер мог сообщить об ошибке и завершить аутентификацию. Если ответ корректен, данные проблемы возвратов механизма, которые будут отправлены клиенту, и указывает, полна ли аутентификация. Отметьте, что данные проблемы могут сопровождать индикацию "успеха". Это могло бы использоваться, например, чтобы сказать клиенту завершать некоторое согласованное состояние.

Используя Согласованный Уровень Безопасности

Некоторые механизмы SASL поддерживают только аутентификацию, в то время как другие поддерживают использование согласованного уровня безопасности после аутентификации. Функция уровня безопасности часто не используется, когда приложение использует некоторые другие средства, такие как SSL/TLS, чтобы связаться надежно с коллегой.

Когда уровень безопасности был согласован, вся последующая передача с коллегой должна иметь место, используя уровень безопасности. Чтобы определить, был ли уровень безопасности согласован, получите согласованное качество защиты (QOP) от механизма. Вот пример того, как определить, был ли уровень безопасности согласован.

String qop = (String) sc.getNegotiatedProperty(Sasl.QOP);
boolean hasSecurityLayer = (qop != null && 
    (qop.equals("auth-int") || qop.equals("auth-conf")));

Уровень безопасности был согласован, если свойство Sasl.QOP указывает, что любая целостность и/или конфиденциальность были согласованы.

Связываться с коллегой, используя согласованный уровень, приложение первое использование метод wrap, чтобы закодировать данные, которые будут отправлены коллеге, чтобы произвести "обернутый" буфер. Это тогда передает поле длины, представляющее число октетов в обернутом буфере, сопровождаемом содержанием обернутого буфера к коллеге. Коллега, получающая поток октетов, передает буфер (без поля длины) к unwrap, чтобы получить декодируемые байты, отправленные коллегой. Детали этого протокола описываются в RFC 2222. Вот пример того, как клиентское приложение отправляет и получает данные приложения, используя уровень безопасности.

// Send outgoing application data to peer
byte[] outgoing = ...;
byte[] netOut = sc.wrap(outgoing, 0, outgoing.length);

send(netOut.length, netOut);   // send to peer

// Receive incoming application data from peer
byte[] netIn = receive();      // read length and ensuing bytes from peer

byte[] incoming = sc.unwrap(netIn, 0, netIn.length);

Как Механизмы SASL Устанавливаются и Выбираются

Реализации механизма SASL обеспечиваются поставщиками систем обеспечения безопасности SASL. Каждый провайдер может поддерживать один или более механизмов SASL и регистрируется в Архитектуре Криптографии Java (JCA). По умолчанию, в J2SE 5, провайдер SunSASL автоматически регистрируется как провайдер JCA. Чтобы удалить это или переупорядочить ее приоритет как провайдера JCA, измените строку
security.provider.7=com.sun.security.sasl.Provider
в файле Свойств Безопасности Java ($JAVA_HOME/lib/security/java.security).

Чтобы добавить или удалить провайдера SASL, Вы добавляете или удаляете соответствующую строку в файле Свойств Безопасности. Например, если Вы хотите добавить провайдера SASL и иметь его механизмы быть предпочтенными тем же самым, реализованным провайдером SunSASL, тогда Вы добавили бы строку к файлу Свойств Безопасности с более низким числом.

security.provider.7=com.example.MyProvider
security.provider.8=com.sun.security.sasl.Provider

Альтернативно, можно программно добавить своего собственного провайдера, используя класс java.security.Security. Например, следующий пример кода регистрирует com.example.MyProvider к списку доступных поставщиков систем обеспечения безопасности SASL.

Security.addProvider(new com.example.MyProvider());
Когда приложение запрашивает механизм SASL, предоставляя одно или более имен механизма, платформа SASL ищет зарегистрированных провайдеров SASL, которые поддерживают тот механизм, проходя через, в порядке, списке зарегистрированных провайдеров. Провайдеры должны тогда определить, соответствует ли требуемый механизм свойства политики выбора и если так, возвратите реализацию для механизма.

Свойства политики выбора определяют аспекты безопасности механизма, такие как его чувствительность к определенным атакам. Они - характеристики механизма (определение), а не его реализация, таким образом, все провайдеры должны прийти к тому же самому заключению об определенном механизме. Например, ПРОСТОЙ механизм восприимчив к атакам простого текста независимо от того, как он реализуется. Если никакие свойства политики выбора не предоставляются, нет никаких ограничений на выбранный механизм. Используя эти свойства, приложение может гарантировать, что не использует неподходящие механизмы, которые могли бы быть развернуты в среде выполнения. Например, приложение могло бы использовать следующий пример кода, если это не хочет позволять использование механизмов, восприимчивых к атакам простого текста.

Map props = new HashMap();
props.add(Sasl.POLICY_NOPLAINTEXT, "true");
SaslClient sc = Sasl.createSaslClient(mechanisms,
    authzid, protocol, serverName, props, callbackHandler);
См. класс Sasl для описаний свойств политики выбора.

Провайдер SunSASL

Провайдер SunSASL поддерживает следующие механизмы клиента и сервера.

Клиентские Механизмы

Провайдер SunSASL поддерживает несколько механизмов SASL, используемых в популярных протоколах, таких как LDAP, IMAP, и SMTP. Следующая таблица суммирует клиентские механизмы и их необходимый ввод.
Клиентское Имя Механизма Параметры/Ввод Обратные вызовы Свойства конфигурации Политика выбора
CRAM-MD5  идентификатор авторизации (как имя пользователя по умолчанию) NameCallback
PasswordCallback
  Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
ОБЗОР-MD5  идентификатор авторизации
 идентификатор протокола
 имя сервера
NameCallback
PasswordCallback
RealmCallback
RealmChoiceCallback
Sasl.QOP
Sasl.STRENGTH
Sasl.MAX_BUFFER
Sasl.SERVER_AUTH
"javax.security.sasl.sendmaxbuffer"
"com.sun.security.sasl.digest.cipher"
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
ВНЕШНИЙ  идентификатор авторизации
внешний канал
    Sasl.POLICY_NOPLAINTEXT
Sasl.POLICY_NOACTIVE
Sasl.POLICY_NODICTIONARY
GSSAPI  Предмет JAAS
 идентификатор авторизации
 идентификатор протокола
 имя сервера
  Sasl.QOP
Sasl.MAX_BUFFER
Sasl.SERVER_AUTH
"javax.security.sasl.sendmaxbuffer"
Sasl.POLICY_NOACTIVE
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
ПЛОСКОСТЬ  идентификатор авторизации NameCallback
PasswordCallback
  Sasl.POLICY_NOANONYMOUS

Приложение, которое использует эти механизмы от провайдера SunSASL, должно предоставить обязательные параметры, обратные вызовы и свойства. Свойства имеют разумные значения по умолчанию и только должны быть установлены, если приложение хочет переопределить значения по умолчанию. Большинство параметров, обратных вызовов, и свойств описываются в документации API. Следующие разделы описывают специфичные для механизма поведения и параметры, не уже охваченные документацией API.

Давка-MD5

Клиентский механизм Давки-MD5 использует параметр идентификатора авторизации, если предоставлено, как имя пользователя по умолчанию в NameCallback ходатайствовать перед приложением/конечным пользователем об идентификаторе аутентификации. Идентификатор авторизации иначе не используется механизмом Давки-MD5; только идентификатором аутентификации обмениваются с сервером.

Обзор-MD5

Механизм Обзора-MD5 используется для дайджест-аутентификации и дополнительного установления уровня безопасности. Это определяет следующие шифры для использования с уровнем безопасности: Тройной DES, DES и RC4 (128, 56, и 40 битов). Механизм Обзора-MD5 может поддерживать только шифры, которые доступны на платформе. Например, если платформа не будет поддерживать шифры RC4, то механизм Обзора-MD5 не будет использовать те шифры.

Свойство Sasl.STRENGTH поддерживает "высоко", "носитель", и "низкие" настройки; его значение по умолчанию является "высоким, средним, низко". Шифры отображаются на настройки силы следующим образом.

Сила Шифр Идентификатор шифра
высоко Тройной DES
RC4  128 битов
3des rc4
носитель DES
RC4  56 битов
des rc4-56
низко RC4  40 битов rc4-40

Когда есть больше чем один выбор для определенной силы, выбранный шифр зависит от доступности шифров в базовой платформе. Чтобы явно назвать шифр, чтобы использовать, установите "com.sun.security.sasl.digest.cipher" свойство в соответствующий идентификатор шифра. Отметьте, что эта установка свойства должна быть совместимой с Sasl.STRENGTH и шифрами, доступными в базовой платформе. Например, Sasl.STRENGTH, устанавливаемый в "низкий" и "com.sun.security.sasl.digest.cipher", устанавливаемый в "3des", является несовместимым. У "com.sun.security.sasl.digest.cipher" свойства нет никакого значения по умолчанию.

"javax.security.sasl.sendmaxbuffer" свойство определяет (строковое представление), максимум отправляет размер буфера в байтах. Значение по умолчанию 65536. Фактическое максимальное количество байтов будет минимумом этого числа, и максимум коллеги получают размер буфера.

GSSAPI

Механизм GSSAPI используется для Kerberos v5 аутентификация и дополнительное установление уровня безопасности. Механизм ожидает вызывающий поток Subject содержать учетные данные Kerberos клиента или что учетные данные могли быть получены, неявно входя в систему к Kerberos. Чтобы получить учетные данные Kerberos клиента, используйте Службу Аутентификации и авторизации Java (JAAS), чтобы войти в систему, используя модуль входа в систему Kerberos. См. GSS-API Java и Учебные руководства JAAS для Использования с Kerberos для деталей и примеров. После использования аутентификации JAAS, чтобы получить учетные данные Kerberos, Вы помещаете код, который использует SASL GSSAPI механизм в пределах doAs или doAsPrivileged.
LoginContext lc = new LoginContext("JaasSample", new TextCallbackHandler());
lc.login();
lc.getSubject().doAs(new SaslAction());

class SaslAction implements java.security.PrivilegedAction {
   public class run() {
       ...
       String[] mechanisms = new String[]{"GSSAPI"};
       SaslClient sc = Sasl.createSaslClient(mechanisms,
           authzid, protocol, serverName, props, callbackHandler);
       ...
   }
}
Чтобы получить учетные данные Kerberos, не делая явное программирование JAAS, см. GSS-API Java и Учебные руководства JAAS для Использования с Kerberos. При использовании этого подхода нет никакой потребности обернуть код в пределах doAs или doAsPrivileged.

"javax.security.sasl.sendmaxbuffer" свойство определяет (строковое представление), максимум отправляет размер буфера в байтах. Значение по умолчанию 65536. Фактическое максимальное количество байтов будет минимумом этого числа, и максимум коллеги получают размер буфера.

Механизмы сервера

Вот таблица, которая суммирует механизмы сервера и их необходимый ввод.
Имя Механизма сервера Параметры/Ввод Обратные вызовы Свойства конфигурации Политика выбора
CRAM-MD5  имя сервера AuthorizeCallback
NameCallback
PasswordCallback
  Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
ОБЗОР-MD5  идентификатор протокола
 имя сервера
AuthorizeCallback
NameCallback
PasswordCallback
RealmCallback
Sasl.QOP
Sasl.STRENGTH
Sasl.MAX_BUFFER
"javax.security.sasl.sendmaxbuffer"
"com.sun.security.sasl.digest.realm"
"com.sun.security.sasl.digest.utf8"
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT
GSSAPI  Предмет JAAS
 идентификатор протокола
 имя сервера
AuthorizeCallback Sasl.QOP
Sasl.MAX_BUFFER
"javax.security.sasl.sendmaxbuffer"
Sasl.POLICY_NOACTIVE
Sasl.POLICY_NOANONYMOUS
Sasl.POLICY_NOPLAINTEXT

Приложение, которое использует эти механизмы от провайдера SunSASL, должно предоставить обязательные параметры, обратные вызовы и свойства. Свойства имеют разумные значения по умолчанию и только должны быть установлены, если приложение хочет переопределить значения по умолчанию.

У всех пользователей механизмов сервера должен быть обработчик обратного вызова, который имеет дело с AuthorizeCallback. Это используется механизмами, чтобы определить, разрешают ли аутентифицируемому пользователю действовать от имени требуемого идентификатора авторизации, и также получить канонизировавшее имя авторизованного пользователя (если канонизация применима).

Большинство параметров, обратных вызовов, и свойств описываются в документации API. Следующие разделы описывают специфичные для механизма поведения и параметры, не уже охваченные документацией API.

Давка-MD5

Механизм сервера Давки-MD5 использует NameCallback и PasswordCallback, чтобы получить пароль, требуемый проверять ответ клиента SASL. Обработчик обратного вызова должен использовать NameCallback.getDefaultName() в качестве ключа, чтобы выбрать пароль.

Обзор-MD5

Механизм сервера Обзора-MD5 использует RealmCallback, NameCallback, и PasswordCallback, чтобы получить пароль, требуемый проверять ответ клиента SASL. Обработчик обратного вызова должен использовать
RealmCallback.getDefaultText() и NameCallback.getDefaultName() как ключи, чтобы выбрать пароль.

"javax.security.sasl.sendmaxbuffer" свойство описывается в клиентском разделе Обзора-MD5.

"com.sun.security.sasl.digest.realm" свойство используется, чтобы определить список разделенных пробелом имен области, которые поддерживает сервер. Список отправляется клиенту как часть проблемы. Если это свойство не было установлено, область по умолчанию является именем сервера (предоставленный в качестве параметра).

"com.sun.security.sasl.digest.utf8" свойство используется, чтобы определить кодировку символов, чтобы использовать. "истина" означает использовать кодирование UTF-8; "ложь" означает использовать латынь ISO 1 (ISO-8859-1). Значение по умолчанию является "истиной".

GSSAPI

У механизма сервера GSSAPI есть те же самые требования как клиентский механизм GSSAPI с точки зрения учетных данных Kerberos и "javax.security.sasl.sendmaxbuffer" свойства.

Отладка и Контроль

Провайдер SunSASL использует API Журналирования, чтобы обеспечить вывод журналирования реализации. Этим выводом можно управлять при использовании конфигурационного файла журналирования и программируемого API (java.util.logging). Именем регистратора, используемым провайдером SunSASL, является "javax.security.sasl". Вот демонстрационный конфигурационный файл журналирования, который включает уровню журналирования FINEST для провайдера SunSASL.
javax.security.sasl.level=FINEST
handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINEST

Таблица ниже показывает механизмы и вывод журналирования, что они генерируют.

Механизм Журналирование Уровня Зарегистрированная информация
CRAM-MD5 FINE Свойства конфигурации; сообщения проблемы/ответа
ОБЗОР-MD5 INFO Сообщение, отброшенное из-за кодирования проблемы
(например, несогласованный MACs, неправильное дополнение)
ОБЗОР-MD5 FINE Свойства конфигурации; сообщения проблемы/ответа
ОБЗОР-MD5 FINER Более подробная информация о сообщениях проблемы/ответа
ОБЗОР-MD5 FINEST Буферами обмениваются в уровне безопасности
GSSAPI FINE Свойства конфигурации; сообщения проблемы/ответа
GSSAPI FINER Более подробная информация о сообщениях проблемы/ответа
GSSAPI FINEST Буферами обмениваются в уровне безопасности

Реализация Поставщика систем обеспечения безопасности SASL

Есть три основных шага в реализации поставщика систем обеспечения безопасности SASL.
  1. Запишите класс, который реализует интерфейс SaslServer или SaslClient.
  2. Запишите класс фабрики (который реализует SaslClientFactory или SaslServerFactory), который создает экземпляры класса.
  3. Запишите провайдера JCA, который регистрирует фабрику.

Первый шаг включает обеспечение реализации для механизма SASL. Чтобы реализовать клиентский механизм, Вы должны реализовать методы, объявленные в интерфейсе SaslClient. Точно так же для механизма сервера, Вы должны реализовать методы, объявленные в интерфейсе SaslServer. В целях этого обсуждения предположите, что Вы разрабатываете реализацию для клиентского механизма "ДЕМОНСТРАЦИОННЫЙ МЕХАНИК", реализованный классом, com.example.SampleMechClient. Следует решить то, что вводит, необходимы механизму и как реализация собирается собрать их. Например, если бы механизм является username/password-based, то реализация должна была бы, вероятно, собрать ту информацию через параметр обработчика обратного вызова.

Следующий шаг включает обеспечение класса фабрики, который создаст экземпляры com.example.SampleMechClient. Фабрика должна определить характеристики механизма, который она поддерживает (как описано свойствами Sasl.POLICY_*) так, чтобы она могла возвратить экземпляр механизма, когда пользователь API запрашивает это использующий совместимые свойства политики. Фабрика может также проверить на законность параметров прежде, чем создать механизм. В целях этого обсуждения предположите, что класс фабрики называют com.example.MySampleClientFactory. Хотя наша демонстрационная фабрика ответственна только за один механизм, единственная фабрика может быть ответственной за любое число механизмов.

Заключительный шаг включает создание провайдера JCA. Шаги для того, чтобы создать провайдера JCA описываются подробно в документе, Как Реализовать Провайдера для Архитектуры Криптографии Java. Клиентские фабрики SASL регистрируются, используя имена свойства формы

SaslClientFactory. mechName

в то время как фабрики сервера SASL регистрируются, используя имена свойства формы

SaslServerFactory. mechName

mechName является именем механизма SASL. Это - то, что возвращается SaslClient.getMechanismName() и SaslServer.getMechanismName(). Продолжаясь с нашим примером, вот то, как провайдер зарегистрировал бы механизм "ДЕМОНСТРАЦИОННОГО МЕХАНИКА".

put("SaslClientFactory.SAMPLE-MECH", "com.example.MySampleClientFactory");

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


Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами