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

Содержание документации

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

1. Введение
   • Что является SASL
   • Java API SASL
   • Когда Использовать SASL
2. Краткий обзор API
   • Создание Механизмов
   • Передача Ввода к Механизмам
   • Используя Механизмы
   • Используя Согласованный Уровень Безопасности
3. Как Механизмы SASL Устанавливаются и Выбираются
4. Провайдер SunSASL
   • Клиентские Механизмы
   • Механизмы сервера
   • Отладка и Контроль
5. Реализация Поставщика систем обеспечения безопасности SASL

Введение

Каков SASL?

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

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

Java API SASL

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

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

При сравнении с 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

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

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

Sasl class используется для того, чтобы создать экземпляры 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, таких как те для того, чтобы собрать область и информацию об авторизации, или даже (нестандартизировали) специфичные для механизма обратные вызовы. Приложение должно быть в состоянии разместить множество механизмов. Следовательно, его обработчик обратного вызова должен быть в состоянии обслужить все обратные вызовы, которые могли бы запросить механизмы. Это не возможно вообще для произвольных механизмов, но обычно выполнимо из-за ограниченного количества механизмов, которые обычно развертываются и используются.

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

// 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;
    }
}

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

Когда уровень безопасности был согласован, вся последующая передача с коллегой должна иметь место, используя уровень безопасности. Чтобы определить, был ли уровень безопасности согласован, получите согласованное качество защиты (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 Устанавливаются и Выбираются

security.provider.7=com.sun.security.sasl.Provider

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

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

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

Security.addProvider(new com.example.MyProvider());

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

Map props = new HashMap();
props.add(Sasl.POLICY_NOPLAINTEXT, "true");
SaslClient sc = Sasl.createSaslClient(mechanisms,
    authzid, protocol, serverName, props, callbackHandler);

Провайдер SunSASL

• Клиентские Механизмы
  • ПЛОСКОСТЬ (RFC 2595). Этот механизм поддерживает имя пользователя/аутентификацию по паролю открытого текста.
  • CRAM-MD5 (RFC 2195). Этот механизм поддерживает хешированную схему имени пользователя/аутентификации по паролю.
  • ОБЗОР-MD5 (RFC 2831). Этот механизм определяет, как Дайджест-аутентификация HTTP может использоваться в качестве механизма SASL.
  • GSSAPI (RFC 2222). Этот механизм использует GSSAPI для того, чтобы получить информацию об аутентификации. Это поддерживает Kerberos v5 аутентификация.
  • ВНЕШНИЙ (RFC 2222). Этот механизм получает информацию об аутентификации из внешнего канала (такого как TLS или IPsec).
• Механизмы сервера
  • CRAM-MD5
  • ОБЗОР-MD5
  • GSSAPI (Kerberos v5)

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

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

Давка-MD5

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

Обзор-MD5

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

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

Когда есть больше чем один выбор для определенной силы, выбранный шифр зависит от доступности шифров в базовой платформе. Чтобы явно назвать шифр, чтобы использовать, установите "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

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);
       ...
   }
}

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

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

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

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

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

Давка-MD5

Обзор-MD5

"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

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

javax.security.sasl.level=FINEST
handlers=java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level=FINEST

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

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

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

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

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

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

SaslClientFactory. mechName

SaslServerFactory. mechName

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

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

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

---

Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.

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