Общие сведения о Kerberos-аутентификации и особенности реализации в приложении

Основные понятия и определения

Основные понятия и определения:

  • Kerberos — сетевой протокол аутентификации, позволяющий безопасно передавать данные через незащищенные сети для безопасной идентификации.

    Kerberos — набор бесплатного программного обеспечения от Массачусетского технологического института MIT (Massachusetts Institute of Technology), разработавшего этот протокол.

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

  • Realm — область (домен) аутентификации в инфраструктуре Kerberos. Значение регистрозависимое.
  • SPN (Service Principal Name) — имя участника службы (уникальное имя), по которому идентифицируется экземпляр сервиса. Это способ сопоставить учетную запись Windows, ответственную за запуск экземпляра службы, с сервером и службой
  • UPN (User Principal Name) — логин пользователя, представляет собой имя, сокращенное относительно полного имени пользователя. Пример: user@domain.ru
  • KDC (Key Distribution Center) — сервер аутентификации в инфраструктуре Kerberos. Контроллер домена.

Механизм аутентификации SPNEGO

Механизм аутентификации SPNEGO:

  1. Пользователь входит в домен под своей учетной записью.
  2. Пользователь открывает в браузере ссылку на приложение. Браузер отправляет в приложение GET запрос.
  3. Приложение возвращает браузеру ответ с кодом 401 и заголовком Authenticate: Negotiate, таким образом приложение инициирует SPNEGO аутентификацию.

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

    Браузер извлекает из запрошенного адреса имя сервера (hostname) и формирует SPN. Сформированный SPN отправляется домен-контроллеру для получения kerberos-билета с помощью запроса TGS_REQ. Если отправленный SPN зарегистрирован в домене, то домен-контроллер выдает пользователю kerberos-билет для доступа в приложение.

  5. Браузер отправляет kerberos-билет в приложение в заголовке HTTP-запроса.

  6. Приложение расшифровывает полученный kerberos-билет, используя долговременный ключ шифрования из keytab-файла.

    Приложение извлекает из kerberos-билета имя пользователя и производит поиск пользователя во внутренней базе данных для определения прав.

  7. Если пользователь найден, приложение возвращает браузеру ответ с кодом 200 и пользователь успешно входит в приложение.

Принцип поиска логина во внутренней базе данных при прозрачной аутентификации

После успешной проверки kerberos-билета от пользователя:

  1. Приложение извлекает логин из kerberos-билета, например, user@msk.example.com.

    Логин из kerberos-билета соответствует атрибуту sAMAccountName в Active Directory.

  2. Приложение производит последовательный поиск нескольких вариантов логина во внутренней базе данных:

    1. "user"
    2. "user@MSK.EXAMPLE.COM"
    3. "user@MSK"
    4. "MSK\user"

  3. Если поиск завершился успешно и найден ровно один вариант, приложение разрешает вход под найденным пользователем.

    Если логин не найден или найдено более одного варианта логина, возвращается ошибка.

Включить или отключить регистронезависимость логинов можно в конфигурационном файле dbaccess.properties (параметр login.casesensitive).

Требования к инфраструктуре для использования Kerberos-аутентификации

Требования к инфраструктуре для использования прозрачной аутентификации с использованием протокола Kerberos (дополнение к техническим требованиям):

  • наличие KDC — сервер аутентификации в инфраструктуре Kerberos, контроллер домена Active Directory под управлением ОС MS Windows Server 2008 R2 и выше;
  • рабочие станции пользователей под управлением ОС MS Windows XP и выше;
  • используемый браузер Microsoft Edge, Mozilla Firefox 3.6 и выше, Google Chrome 18,19 и выше;
  • рабочие станции пользователей включены в домен, пользователи используют доменные учетные записи;
  • логины пользователей в системе должны соответствовать логинам в Active Directory (как правило, для этого используется механизм импорта оргструктуры из Active Directory);
  • при использовании разветвленной доменной инфраструктуры, в случае если домен пользователя отличается от домена KDC, между доменами должны быть установлены двусторонние доверительные отношения на уровне лесов (Forest Trust).

Для сервера приложения не обязательно:

  • иметь доступ до контроллеров домена, если только одновременно не настроена LDAP-аутентификация на форме;
  • принадлежать домену, в котором настраивается аутентификация;
  • запускаться под доменной учетной записью.

Прозрачная аутентификация может работать на удаленном рабочем столе (пользователь должен войти под доменной учетной записью).