Kerberos

Пользователи AggreGate Server могут быть аутентифицированы через центр распределения ключей Kerberos с помощью плагина Kerberos Authentication. Механизм аутентификации Kerberos реализован с использованием JAAS (Java Authentication and Authorization Service) и GSS-API (Generic Security Services Application Program Interface) и поддерживает Kerberos V5.

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

Пользовательские права для успешно аутентифицированных пользователей будут назначены в соответствии с их роль учетной записи пользователя в AggreGate Server.

Требования

  • Доменное имя Kerberos Key Distribution Center (KDC) должно быть доступно как с клиента AggreGate, так и с сервера AggreGate.

  • Директор службы, представляющий сервер AggreGate, должен быть добавлен в соответствующее царство на KDC.

  • Все принципы пользователей должны быть добавлены в то же царство на KDC, что и принципал службы.

  • На KDC должна быть включена функция предварительной аутентификации.

  • Базовая операционная система должна поддерживать кэш билетов.

Конфигурация

Конфигурация плагина Kerberos

Плагин Kerberos Authentication требует настройки следующих полей:

  • Username Mapping. Сопоставление между AggreGate Server пользователями и именами принципов пользователей Kerberos. Если зарегистрированный принцип пользователя Kerberos пытается войти в систему, а соответствующий пользователь AggreGate Server не найден в таблице сопоставления, возникает исключение.

Имя принципала пользователя Kerberos

Уникальное имя в системе Kerberos, которому Kerberos может назначить билеты для доступа к службам, поддерживающим Kerberos.

Имя пользователя AggreGate Server

Имя пользователя AggreGate Server учётная запись пользователя которая соответствует имени принципа Kerberos.

  • Имя принципала службы. Уникальный идентификатор экземпляра службы, который будет использоваться для аутентификации пользователей.

  • Пароль. Пароль принципала службы.

  • Область (Realm). Домен, в котором сервер аутентификации имеет полномочия для аутентификации.

  • KDC. Домен центра распределения ключей.

  • Количество попыток подключения. Максимальное количество попыток подключения к KDC.

  • Время ожидания. Указывает время ожидания между попытками подключения к KDC.

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

Глобальная конфигурация сервера

После настройки плагина аутентификации Kerberos выберите "Kerberos Authentication" в свойстве глобальной конфигурации сервера внешняя аутентификация.

Конфигурация и запуск клиента

Для запуска клиента AggreGate в режиме Kerberos используются перечисленные ниже параметры командной строки. Обратите внимание, что значения, введенные для параметров, должны точно соответствовать значениям, указанным в плагине Kerberos на AggreGate Server.

Параметр

Описание

-kerberos

Запускает клиент AggreGate в режиме Kerberos.

-kdc

Домен центра распределения ключей (KDC), указанный в конфигурации плагина Kerberos.

-realm

Область Kerberos, указанная в конфигурации плагина Kerberos.

-servicePrincipal

Имя принципала службы, представляющего AggreGate Server.

-numConnectionAttempts

Количество попыток подключения клиента AggreGate к KDC перед тем, как будет выдано исключение. Необязательно, по умолчанию 3.

-waitingTime

Время ожидания между попытками подключения в секундах. Необязательно, по умолчанию 3.

Пример запуска клиента AggreGate в режиме Kerberos из командной строки выглядит следующим образом:

~# bash client -kerberos -realm EXAMPLE.COM -kdc kdc.example.com -servicePrincipal aggserver

Вход клиента

Когда клиент AggreGate запускается в режиме Kerberos, диалог аутентификации дает пользователю возможность пройти аутентификацию через SSO или путем ввода имени и пароля пользователя принципа Kerberos. Отображаются следующие поля:

  • IP-адрес. Адрес целевого сервера AggreGate, с которым пытается соединиться клиент.

  • Порт. Порт целевого сервера AggreGate, к которому пытается подключиться клиент.

  • SSO. Если выбрано, механизм аутентификации пытается получить Ticket Granting Ticket (TGT) из Ticket Cache базовой операционной системы, не требуя ввода имени пользователя и пароля.

  • Имя пользователя. Имя пользователя по принципу Kerberos. Используется только в том случае, если SSO не выбран.

  • Пароль. Пароль, соответствующий имени пользователя принципа Kerberos. Используется только в том случае, если SSO не выбран.

Если флаг SSO не установлен, базовый механизм аутентификации подключается к KDC для выполнения процедуры предварительной аутентификации Kerberos и получения Ticket Granting Ticket (TGT).

Подробности

Процесс аутентификации

Как только клиент получает Ticket Granting Ticket (TGT), он используется для получения служебного билета для целевого сервера (определенного параметром командной строки "-servicePrincipal"). Сервисный билет шифруется с помощью долгосрочного секретным ключом сервера и инкапсулируется как часть сообщения AP-REQ. Токен, содержащий это сообщение AP-REQ, затем передается в качестве параметра в функцию authenticate плагина KerberosAuthPlugin. Только авторизованный пользователь Kerberos может получить такой токен от KDC.

Имя принципала службы и пароль используются при инициализации плагина для получения долгосрочного секретного ключа сервера от KDC (используется предварительная аутентификация Kerberos). Этот ключ затем используется для расшифровки сервисного билета, который является частью сообщения AP-REQ, отправленного клиентом AggreGate. Если расшифровка прошла успешно и контрольные суммы совпали, аутентификация считается успешной.

Токены

Когда соединение клиента с сервером установлено, оно не будет прервано, даже если срок действия соответствующего маркера Kerberos истечет. Более того, при нажатии кнопки "Обновить" на соответствующем соединении с Сервером будет автоматически получен новый токен (как со стороны Клиента, так и со стороны Сервера). (как на стороне Клиента, так и на стороне Сервера), если срок действия текущего токена истек.