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

Часть VI: Аутентификация HTTP/SPNEGO

Упражнение 9: Используя Аутентификацию HTTP/SPNEGO

Что является HTTP SPNEGO

HTTP SPNEGO поддерживает Согласовывать схему аутентификации в передаче HTTP. SPNEGO поддерживает типы аутентификации:

Веб-Аутентификация

Веб-сервер отвечает

       HTTP/1.1 401 Unauthorized
       WWW-Authenticate: Negotiate

клиент должен будет отправить заголовок как

       Authorization: Negotiate YY.....

аутентифицировать себя к серверу

Аутентификация прокси

Ответы веб-сервера с

       HTTP/1.1 407 Proxy Authentication Required
       Proxy-Authenticate: Negotiate

клиент должен будет отправить заголовок как

       Proxy-Authorization: Negotiate YY.....

аутентифицировать себя к прокси-серверу

Эта функция поддерживает оба типа аутентификации.

Как использовать Аутентификацию HTTP/SPNEGO

Нет никакой новой общедоступной API-функции, включенной в новую функцию, но несколько конфигураций необходимы, чтобы выполнить передачу успеха:

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, или имя пользователя и пароль, обеспеченный Аутентификатором, являются неправильными), тогда вторая самая сильная схема будет автоматически использоваться.

Отметьте: Если http.auth.preference устанавливается в SPNEGO или Kerberos, тогда SPNEGO предполагает, что Вы только хотите попробовать схему Negotiate, даже если это перестало работать. SPNEGO не будет, нейтрализация к любой другой схеме и Вашей программе бросит 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"; // your password for the 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);
    }
}

Листинг кода для krb.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 и/или его филиалы. Все права защищены.
Свяжитесь с Нами