SSL и Пользовательские Сокеты (Учебные руководства Java™> Именование Java и Интерфейс Каталога> Усовершенствованные Темы для Пользователей LDAP)


След: Именование Java и Интерфейс Каталога
Урок: Усовершенствованные Темы для Пользователей LDAP
Раздел: Безопасность
SSL и Пользовательские Сокеты
Домашняя страница > Именование Java и Интерфейс Каталога > Усовершенствованные Темы для Пользователей LDAP

SSL и Пользовательские Сокеты

В дополнение к аутентификации SASL большинство серверов LDAP позволяет их службам быть полученными доступ через SSL. SSL особенно полезен для LDAP v2 серверы, потому что v2 протокол не поддерживает аутентификацию SASL.

Поддерживающий SSL сервер часто поддерживает SSL двумя способами. Самым основным способом сервер поддерживает порты SSL в дополнение к нормальным (незащищенным) портам. Другой путь, которым сервер поддерживает SSL, через использование Расширения TLS Запуска (RFC 2830). Эта опция доступна только LDAP v3 серверы и описывается подробно в разделе.

Используя Свойство Сокета SSL

По умолчанию поставщик услуг Sun LDAP использует простые сокеты, связываясь с сервером LDAP. Чтобы запросить что сокеты SSL быть использованием, установите свойство Context.SECURITY_PROTOCOL в "ssl".

В following example, сервер LDAP предлагает SSL в порту 636. Чтобы выполнить эту программу, следует включить SSL на порту 636 на Вашем сервере LDAP. Эта процедура обычно выполняется администратором каталога.


Требования сервера: сервер LDAP должен быть установлен с сертификатом сервера SSL X.509 и включать SSL. Как правило, следует сначала получить подписанный сертификат для сервера от центра сертификации (CA). Затем, следуйте инструкциям от своего поставщика каталога на том, как включить SSL. У различных поставщиков есть различные инструменты для того, чтобы сделать это.

Для Сервера каталогов Java Sun, v5.2, используют Управлять инструмент Сертификатов в Консоли администрирования, чтобы генерировать Запрос Подписания Сертификата (CSR). Представьте CSR CA, чтобы получить сертификат сервера SSL X.509. Используя Консоль администрирования, добавьте сертификат списку сервера сертификатов. Также установите сертификат CA, если это уже не находится в списке сервера доверяемой АВАРИИ, Включают SSL при использовании вкладки Configuration в Консоли администрирования. Выберите сервер в левой области. Выберите вкладку Encryption в правильной области. Щелкните по флажкам для, "Включают SSL для этого сервера", и "Используют это семейство шифра: RSA", гарантируя, что сертификат сервера Вы добавили, находится в списке сертификатов.

Клиентские Требования: Вы должны гарантировать, что клиент доверяет серверу LDAP, который Вы будете использовать. Следует установить сертификат сервера (или сертификат его CA) в базе данных Вашего JRE доверяемых сертификатов. Вот пример.

# cd JAVA_HOME/lib/security
# keytool -import -file server_cert.cer -keystore jssecacerts

Для получения информации о том, как использовать средства обеспечения безопасности, см., что Безопасность запаздывает. Для получения информации о JSSE см. Расширение Защищенного сокета Java (JSSE) Справочник.


// Set up the environment for creating the initial context
Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:636/o=JNDITutorial");

// Specify SSL
env.put(Context.SECURITY_PROTOCOL, "ssl");

// Authenticate as S. User and password "mysecret"
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, 
        "cn=S. User, ou=NewHires,o=JNDITutorial");
env.put(Context.SECURITY_CREDENTIALS, "mysecret");

// Create the initial context
DirContext ctx = new InitialDirContext(env);

// ... do something useful with ctx

Отметьте: Если Вы будете использовать SSL, чтобы соединиться с сервером на порту, который не использует SSL, то Ваша программа зависнет. Точно так же, если Вы будете использовать простой сокет, чтобы соединиться с сокетом SSL сервера, то тогда Ваше приложение зависнет. Это - характеристика протокола SSL.


Используя URL LDAPS

Вместо того, чтобы запросить использование SSL через использование свойства Context.SECURITY_PROTOCOL, можно также запросить использование SSL через использование URL LDAPS. URL LDAPS подобен URL LDAP за исключением того, что схема URL является "ldaps" вместо "ldap". Это определяет использование SSL, связываясь с сервером LDAP.

В following example, сервер LDAP предлагает SSL в порту 636. Чтобы выполнить эту программу, следует включить SSL на порту 636 на Вашем сервере LDAP.

// Set up the environment for creating the initial context
Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");

// Specify LDAPS URL
env.put(Context.PROVIDER_URL, "ldaps://localhost:636/o=JNDITutorial");

// Authenticate as S. User and password "mysecret"
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, 
        "cn=S. User, ou=NewHires, o=JNDITutorial");
env.put(Context.SECURITY_CREDENTIALS, "mysecret");

// Create the initial context
DirContext ctx = new InitialDirContext(env);

// ... do something useful with ctx

Принимаются LDAPS URL принимаются где угодно LDAP URL. Проверьте Учебное руководство JNDI для деталей о LDAP и URL LDAPS.

Аутентификация клиента: Используя SSL с Внешним Механизмом SASL

SSL обеспечивает аутентификацию и другие службы безопасности в нижнем уровне чем LDAP. Если аутентификация была уже сделана на SSL, уровень LDAP может использовать ту информацию об аутентификации от SSL при использовании Внешнего механизма SASL.

following example походит previous SSL example, за исключением того, что вместо того, чтобы использовать простую аутентификацию, это использует Внешнюю аутентификацию SASL. При использовании Внешнего Вы не должны предоставить принципал или информацию о пароле, потому что они поднимаются от SSL.


Требования сервера: Этот пример требует, чтобы сервер LDAP позволил основанную на сертификате аутентификацию клиента. Кроме того, сервер LDAP должен доверять (АВАРИЯ) клиентским сертификатам, которые это получает, и должно быть в состоянии отобразить отличительные имена владельца в клиентских сертификатах принципалам, о которых это знает. Следуйте инструкциям от своего поставщика каталога на том, как выполнить эти задачи.

Клиентские Требования: Этот пример требует, чтобы у клиента был клиентский сертификат SSL X.509. Кроме того сертификат должен быть сохранен как первая ключевая запись в keystore файле. Если эта запись является защищённой паролем, у нее должен быть тот же самый пароль как keystore. Для получения дополнительной информации о JSSE keystores, см. Расширение Защищенного сокета Java (JSSE) Справочник.


// Set up the environment for creating the initial context
Hashtable<String, Object> env = new Hashtable<String, Object>(11);
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:636/o=JNDITutorial");

// Principal and credentials will be obtained from the connection
env.put(Context.SECURITY_AUTHENTICATION, "EXTERNAL");

// Specify SSL
env.put(Context.SECURITY_PROTOCOL, "ssl");

// Create the initial context
DirContext ctx = new InitialDirContext(env);

...

Чтобы выполнить эту программу так, чтобы сертификат клиента использовался для аутентификации, следует обеспечить (как системные свойства) расположение и пароль keystore, содержащего сертификат клиента. Вот пример того, как выполнить программу.

java -Djavax.net.ssl.keyStore=MyKeystoreFile \
    -Djavax.net.ssl.keyStorePassword=mysecret \
    External

Если Вы не предоставите keystore, то программа выполнит использующую анонимную аутентификацию, потому что никакие клиентские учетные данные не существуют на SSL.

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

Используя Пользовательские Сокеты

При использовании SSL провайдер LDAP будет, по умолчанию, использовать фабрику сокета, javax.net.ssl.SSLSocketFactory, для того, чтобы создать сокет SSL, чтобы связаться с сервером, используя значение по умолчанию конфигурация JSSE. JSSE может быть настроен во множестве путей, как детализировано в Расширении Защищенного сокета Java (JSSE) Справочник. Однако, есть времена, когда те настройки не достаточны, и Вы должны иметь больше контроля над сокетами SSL, или сокетами вообще, используемый поставщиком услуг LDAP. Например, Вам, возможно, понадобились бы сокеты, которые могут обойти брандмауэры, или сокеты JSSE, которые используют политики кэширования/извлечения не по умолчанию для его баз доверенных сертификатов и баз ключей. Чтобы установить реализацию фабрики сокета, используемую поставщиком услуг LDAP, установите свойство "java.naming.ldap.factory.socket" в полностью определенное имя class фабрики сокета. Этот class должен реализовать краткий обзор javax.net.SocketFactory class и обеспечить реализацию метода getDefault(), который возвращает экземпляр фабрики сокета. См. Расширение Защищенного сокета Java (JSSE) Справочник.

Вот пример a custom socket factory это производит простые сокеты.

public class CustomSocketFactory extends SocketFactory {
    public static SocketFactory getDefault() {

        System.out.println("[acquiring the default socket factory]");
        return new CustomSocketFactory();
    }
        ...
}

Отметьте, что этот пример создает новый экземпляр CustomSocketFactory каждый раз создается, когда новое соединение LDAP. Это могло бы быть подходящим для некоторых приложений и снабдить фабрики сокетом. Если Вы хотите снова использовать ту же самую фабрику сокета, getDefault() должен возвратить одиночный элемент.

Чтобы использовать эту пользовательскую фабрику сокета с программой JNDI, установите свойство "java.naming.ldap.factory.socket", как показано в following example.

// Set up the environment for creating the initial context
Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://localhost:389/o=JNDITutorial");

// Specify the socket factory
env.put("java.naming.ldap.factory.socket", "CustomSocketFactory");

// Create the initial context
DirContext ctx = new InitialDirContext(env);

// ... do something useful with ctx

Свойство "java.naming.ldap.factory.socket" полезно для установки фабрики сокета на на основание контекста. Другой способ управлять сокетами, используемыми поставщиком услуг LDAP, состоит в том, чтобы установить фабрику сокета для всех сокетов, используемых во всей программе, при использовании java.net.Socket.setSocketImplFactory(). Использование этого метода менее гибко, потому что это влияет на все сокетные соединения, не только соединения LDAP и поэтому, должно использоваться с заботой.


Проблемы с примерами? Попытайтесь Компилировать и Выполнить Примеры: FAQ.
Жалобы? Поздравление? Предложения? Дайте нам свою обратную связь.

Предыдущая страница: обзор-MD5
Следующая страница: Больше Операций LDAP



Spec-Zone.ru - all specs in one place