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

Аутентификация Http

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

Обработчик протокола HTTP реализует много схем аутентификации. Реализация Sun Java Версия 6 SE поддерживает следующее: Каждая из этих схем описывается более подробно ниже, но они обычно используются кодом программы почти таким же способом. java.net. class аутентификатора используется, чтобы включить аутентификации и обеспечить доступ к хранилищу имен пользователей и паролей, которые тогда используются в соответствующих схемах аутентификации.

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

Как использовать Аутентификатор class

Аутентификатором является абстрактный class, который расширяется приложениями и когда-то устанавливается, вызывается, чтобы получить имена пользователей и пароли для взаимодействия при аутентификации.

Расширение java.net. Аутентификатор

Код программы должен переопределить getPasswordAuthentication() метод. Отметьте, метод не абстрактен, и реализация по умолчанию ничего не делает. Следующее является минимальным примером:
    class MyAuthenticator extends Authenticator {

        public PasswordAuthentication getPasswordAuthentication () {
            return new PasswordAuthentication ("user", "password".toCharArray());
        }
    }

Этот простой пример возвращает имя пользователя "пользователь" и пароль для каждого взаимодействия при аутентификации HTTP. Более реалистический пример использовал бы другие методы java.net. Аутентификатор, чтобы получить больше информации о HTTP запрашивает что потребности аутентифицироваться. Любой из следующих методов может вызвать реализация getPasswordAuthentication (), чтобы решить, как обработать каждый запрос на учетные данные.

Включение аутентификации

Определив подходящую реализацию аутентификатора class, аутентификация включается, вызывая
        Authenticator.setDefault (authinstance);

где authinstance экземпляр объявленной реализации class. Если это не вызывают, то аутентификация отключается, и ошибки аутентификации сервера будут возвращены к пользовательскому коду через объекты IOException. После того, как установленный, http реализация попытается аутентифицировать автоматически где только возможно (через кэшируемые учетные данные, или учетные данные, которые могут быть получены от системы). Если корректные учетные данные не доступны тогда, аутентификатор пользователя вызывается, чтобы обеспечить их.

Управление, какая схема аутентификации используется

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

Если пользователь должен гарантировать, что определенная схема используется, то следующее системное свойство может быть установлено изменить поведение значения по умолчанию.

        -Dhttp.auth.preference="scheme"

-D определяется, если свойство устанавливается на командной строке. "http.auth.preference" является именем свойства, и схема является именем схемы использовать. Если сервер не включает эту схему в свой список предложенных схем, то выбор значения по умолчанию делается.

Детали каждой схемы аутентификации

Основной Http

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

getRequestingPrompt () метод возвращает область Стандартной аутентификации в соответствии с сервером.

Обзор Http

Обзор является относительно безопасной схемой, основанной на криптографических хешах имени пользователя и пароля, используя хеш-алгоритм MD5. Обзор также обеспечивает возможность к серверу, чтобы доказать клиенту, что это также знает совместно используемый секрет (пароль). Это поведение обычно отключается, потому что не все серверы поддерживают его. Это может быть включено со следующими системными свойствами:
        -Dhttp.auth.digest.validateServer="true"
        -Dhttp.auth.digest.validateProxy="true"

getRequestingPrompt () метод возвращает область Дайджест-аутентификации в соответствии с сервером.

NTLM

NTLM является схемой, определенной Microsoft. Это - более безопасная схема чем Основной, но менее безопасный чем Обзор. NTLM может использоваться с прокси или серверами, но не с обоими одновременно. Если прокси используется, то он не может использоваться для аутентификации сервера. Это - то, потому что протокол фактически аутентифицирует соединение TCP, а не отдельные взаимодействия HTTP.

На платформах Microsoft Windows аутентификация NTLM пытается получить удостоверения пользователя от системы, не запрашивая объект аутентификатора пользователя. Если эти учетные данные не будут приняты сервером тогда, то аутентификатор пользователя вызовут.

Поскольку Аутентификатор, class был определен до NTLM быть поддерживаемым, не было возможно добавить поддержку в API для поля домена NTLM. Есть три опции для того, чтобы определить домен:

  1. Не определяйте это. В некоторых средах фактически не требуется домен, и приложение не должно определить это.
  2. Доменное имя может быть закодировано в пределах имени пользователя, снабжая префиксом доменное имя, сопровождаемое наклонной чертой влево '\' перед именем пользователя. С этим методом не должны быть изменены существующие приложения, которые используют Аутентификатор class, пока пользователи информируются, что эта нотация должна использоваться.
  3. Если доменное имя не будет определено как в методе 2), и системное свойство "http.auth.ntlm.domain" определяется, то значение этого свойства будет использоваться в качестве доменного имени.

Хттп Согласовывает (SPNEGO)

Согласуйте схема, которая потенциально позволяет любому механизму аутентификации GSS использоваться в качестве протокола аутентификации HTTP. В настоящий момент схема только поддерживает Kerberos и NTLM. NTLM был уже описан выше, таким образом, этот раздел только описывает, как установить Kerberos для аутентификации Http.

Kerberos 5 Конфигураций

Так как механизм SPNEGO вызовет JGSS, который по очереди вызывает Kerberos модуль входа в систему V5, чтобы сделать реальные работы. Kerberos 5 конфигураций необходим. который включает:
            java -Djava.security.krb5.conf=krb5.conf \
                 -Djavax.security.auth.useSubjectCredsOnly=false \
                 ClassName
Например, можно обеспечить файл spnegoLogin.conf:
          com.sun.security.jgss.krb5.initiate {
              com.sun.security.auth.module.Krb5LoginModule
                  required useTicketCache=true;
          };
и выполненный java с:
            java -Djava.security.krb5.conf=krb5.conf \
                 -Djava.security.auth.login.config=spnegoLogin.conf \
                 -Djavax.security.auth.useSubjectCredsOnly=false \
                 ClassName

Имя пользователя и Извлечение Пароля

Точно так же как любая другая схема аутентификации HTTP клиент может обеспечить специализированное java.net.Authenticator чтобы подать имя пользователя и пароль к HTTP модуль SPNEGO, если они необходимы (то есть нет никакого учетного доступного кэша). Единственная информация об аутентификации должна была быть проверена в Вашем Аутентификаторе, схема, которая может быть получена с getRequestingScheme(). Значение должно быть, "Согласовывают". Это означает, что Ваша реализация Аутентификатора будет похожа:
    class MyAuthenticator extends Authenticator {

        public PasswordAuthentication getPasswordAuthentication () {
            if (getRequestingScheme().equalsIgnoreCase("negotiate")) {
                String krb5user;
                char[] krb5pass;
                // get krb5user and krb5pass in your own way
                ....
                return (new PasswordAuthentication (krb5user,
                            krb5pass));
            } else {
                ....
            }
        }
    }
Внимание: Согласно спецификации java.net.Authenticator, это разрабатывается, чтобы получить имя пользователя и пароль одновременно, не, определяют - также principal=xxx в файле конфигурации JAAS.

Предпочтение схемы

Клиент может все еще обеспечить системное свойство http.auth.preference обозначить, что определенная схема должна всегда использоваться пока запрос к серверу на это. Можно использовать "SPNEGO" или "Kerberos" для этого системного свойства. "SPNEGO" означает, что Вы предпочитаете ответу схему Negotiate, используя механизм GSS/SPNEGO; "Kerberos" означает, что Вы предпочитаете ответу схему Negotiate, используя механизм GSS/Kerberos. Обычно, аутентифицируя против продукта Microsoft, можно использовать "SPNEGO". Значение "Kerberos" также работает на серверы Microsoft. Только необходимо, когда Вы встречаетесь с сервером, который знает, Согласовывают, но не знает о SPNEGO. Если http.auth.preference не устанавливается, внутренний порядок choosen: Замеченный, что Kerberos не появляется в этом списке, с тех пор всякий раз, когда Согласовывают, поддерживается, GSS/SPNEGO всегда выбирается.

Нейтрализация

Если сервер обеспечил, больше чем одна схема аутентификации (включая Согласовывают), согласно порядку обработки, упомянутому в последнем разделе, Java попытается бросить вызов схеме Negotiate. Однако, если протокол не может быть установлен успешно (например. kerberos конфигурация не корректна, или имя узла сервера не записывается в DB принципала KDC, или имя пользователя и пароль, обеспеченный Аутентификатором, являются неправильными), тогда 2-ая самая сильная схема будет автоматически использоваться. Внимание: Если http.auth.preference устанавливается в SPNEGO или Kerberos, тогда мы предполагаем, что Вы только хотите попробовать схему Negotiate, даже если это перестало работать. мы не будем, нейтрализация к любой другой схеме и Вашей программе приведет к броску IOException высказывание этого получает 401 или 407 ошибок от ответа HTTP.

Пример

Предположите, что у Вас есть Сервер IIS, работающий на Windows Server в пределах Активного Каталога. Веб-страница на этом сервере конфигурируется, чтобы быть защищенной Аутентификацией Windows Integrated. Это означает, что сервер запросит и Согласовать и аутентификация NTLM.

Вы должны подготовить эти файлы, чтобы получить защищенный файл:

Листинг кода для RunHttpSpnego.java


import java.io.BufferedReader;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.Authenticator;
import java.net.PasswordAuthentication;
import java.net.URL;

public class RunHttpSpnego {

    static final String kuser = "username"; // your account name
    static final String kpass = password; // retrieve password for your account 

    static class MyAuthenticator extends Authenticator {
        public PasswordAuthentication getPasswordAuthentication() {
            // I haven't checked getRequestingScheme() here, since for NTLM
            // and Negotiate, the usrname and password are all the same.
            System.err.println("Feeding username and password for " + getRequestingScheme());
            return (new PasswordAuthentication(kuser, kpass.toCharArray()));
        }
    }

    public static void main(String[] args) throws Exception {
        Authenticator.setDefault(new MyAuthenticator());
        URL url = new URL(args[0]);
        InputStream ins = url.openConnection().getInputStream();
        BufferedReader reader = new BufferedReader(new InputStreamReader(ins));
        String str;
        while((str = reader.readLine()) != null)
            System.out.println(str);
    }
}

Листинг кода для krb5.conf


[libdefaults]
    default_realm = AD.LOCAL
[realms]
    AD.LOCAL = {
        kdc = kdc.ad.local
    }
    

Листинг кода для login.conf


com.sun.security.jgss.krb5.initiate {
  com.sun.security.auth.module.Krb5LoginModule required doNotPrompt=false useTicketCache=true;
};

Затем, скомпилировать RunHttpSpnego.java и выполненный:

java -Djava.security.krb5.conf=krb5.conf \
    -Djava.security.auth.login.config=login.conf \
    -Djavax.security.auth.useSubjectCredsOnly=false \
    RunHttpSpnego \
    http://www.ad.local/hello/hello.html

Вы будете видеть:

Feeding username and password for Negotiate
<h1>Hello, You got me!</h1>

Фактически, если Вы работаете на машине Windows как пользователь домена, или, Вы работаете на Linux или машине Соляриса, которая уже вышла kinit команда и получила учетный кэш. class MyAuthenticator будет полностью проигнорирован, и вывод будет просто

<h1>Hello, You got me!</h1>
который показывает, что с именем пользователя и паролем не консультируются. Это - так называемый Единственный Вход в систему. Кроме того, можно только работать
java RunHttpSpnego \
    http://www.ad.local/hello/hello.html
видеть, как нейтрализация делается, когда Вы будете видеть
Feeding username and password for ntlm
<h1>Hello, You got me!</h1>

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