Включение модулей протоколов WiKID

TL;DR

В этой инструкции объяснено, как включать модули протоколов в сервере WiKID Strong Authentication, настроить LDAP и создавать сетевые клиенты (wAuth). Описаны необходимые параметры, создание сертификатов для wAuth, чеклист для администратора и рекомендации по безопасности.

Введение

Протокольные модули позволяют серверу WiKID Strong Authentication обслуживать разные типы сетевых клиентов. В Community Edition доступны модули LDAP, TACACS+ и нативный wAuth. wAuth — это собственный протокол WiKID, использующий SSL и проверку сертификатов для защищённой передачи данных аутентификации через ненадёжные сети.

Если вы видите демонстрационный интерфейс регистрации (файл /opt/WiKID/tomcat/webapps/WiKIDAdmin/example.jsp или https://servername/WiKIDAdmin/exmample.jsp), он использует Java bean (wClient) для проверки данных пользователей. Редактирование этого файла выполняется отдельно.

Важное: протокол wAuth включён автоматически — остальные протоколы не работают без него.

Обзор доступных модулей

• wAuth — нативный, работает по SSL с сертификатами; необходим для работы других модулей.
• LDAP — позволяет интегрировать проверку по LDAP-bind через WiKID.
• TACACS+ — поддержка аутентификации через TACACS+ (детали конфигурации аналогичны: включение модуля, затем добавление сетевых клиентов).

Рисунок — Список неинициализированных протоколов

Как включить модуль протокола

1. Войдите в административную панель WiKID.
2. Выберите заголовок меню “Protocol Modules” (Модули протоколов).
3. На странице появится список доступных модулей. Если модуль не инициализирован, он будет помечен как неактивный (см. рисунок выше).
4. Для инициализации нажмите на нужный модуль и заполните требуемые параметры.

Ниже — подробная инструкция для LDAP и для создания сетевых клиентов (wAuth).

Включение LDAP-протокола

На странице включения LDAP нажмите на LDAP в списке модулей. Появится форма с обязательными параметрами LDAP-модуля. Параметры и их назначение:

• LDAP_wauth_host: IP-адрес сервера WiKID, который будет проверять LDAP bind-запросы (обычно всегда 127.0.0.1).
• LDAP_wauth_kfile: Путь к P12-сертификату сетевого клиента, используемому для доступа LDAP к серверу WiKID (обычно /opt/WiKID/private/localhost.p12).
• LDAP_wauth_pass: Пароль (passphrase) для P12-файла, указанный выше.
• LDAP_wauth_port: Порт, на котором слушает сервер WiKID (обычно 8388). Примечание: сам LDAP может слушать на 10389.
• LDAP_wauth_server: 12-значный код домена WiKID, против которого будут проверяться bind-запросы.

После заполнения всех полей нажмите “Update” (Обновить) для сохранения конфигурации.

Примечания и советы по LDAP

• LDAP_wauth_host обычно должен оставаться 127.0.0.1, если WiKID и LDAP находятся на одном хосте. В распределённых установках убедитесь, что в сети есть корректный маршрут и что TLS/SSL между компонентами настроен.
• Проверьте права доступа к файлу P12 и его корректность с помощью openssl или аналогичных инструментов прежде чем указывать в форме.

Создание сетевых клиентов (Network Clients)

Сетевой клиент — система, которая запрашивает у WiKID проверку одноразовых паролей (OTP) и действует как прокси между пользователем и WiKID. Для функционирования клиент должен использовать один из включённых протоколов. Порядок действий:

1. В админке выберите “Create new Network Client” (Создать новый сетевой клиент).
2. Заполните общие свойства клиента (независимо от протокола):
   • Name — читабельное имя сервера (рекомендуется: hostname + домен WiKID).
   • IP Address — IP-адрес сетевого клиента.
   • Protocol — выбранный протокол (доступны только ранее включённые модули).
   • Domain — домен аутентификации WiKID, в котором клиент будет запрашивать проверку учётных данных.

Рисунок — Начальный экран сетевого клиента

Создание сертификата для wAuth-клиента

Если вы добавляете wAuth-клиента, необходимо сгенерировать для него сертификат. На форме создания клиента заполните поля для генерации сертификата. Важно: сетевому хосту не обязательно иметь маршрутизируемое FQDN; можно использовать короткое имя или псевдоним, например “www” или “extranet”.

Рисунок — Свойства сетевого клиента

Рисунок — Создание сертификата для wAuth-клиента

Чеклист администратора до ввода в эксплуатацию

• Убедиться, что протокол wAuth активен (обязательное условие).
• Настроить и протестировать LDAP с правильным P12-файлом и паролем.
• Добавить сетевого клиента с корректным IP, именем и доменом.
• Сгенерировать и загрузить сертификат для каждого wAuth-клиента.
• Ограничить список IP-адресов, которым разрешён доступ к WiKID (белый список).
• Настроить резервное копирование P12-файлов и конфигураций.

Рекомендации по безопасности

• Ротация сертификатов: регенерируйте сертификаты локальных и удалённых клиентов по расписанию (например, раз в 6–12 месяцев) или при подозрении на компрометацию.
• Ограничьте доступ по IP и настройте межсетевой экран (firewall) так, чтобы только доверенные сетевые клиенты могли обращаться к портам WiKID.
• Храните P12-файлы и фразы-пароли в защищённом хранилище (Vault, HSM, менеджер секретов).
• Разделяйте привилегии: администратор, оператор и просмотрщик должны иметь разные учётные записи и уровни доступа.

Типичные ошибки и когда конфигурация не работает

• Неправильный путь или пароль к LDAP_wauth_kfile — WiKID не сможет установить SSL-соединение.
• Неверный LDAP_wauth_server (код домена) — bind-запросы будут отклонены.
• Отсутствие включённого wAuth — другие протоколы не будут работать.
• Сертификат клиента просрочен или не соответствует CN/имени хоста — соединение по wAuth будет отклонено.

Методология добавления клиента (мини-процесс)

1. Подготовка: собрать IP, имя хоста, домен WiKID и выбрать протокол.
2. В админке создать запись клиента и заполнить общие поля.
3. Если wAuth — сгенерировать сертификат и сохранить P12 и пароль.
4. Тестирование: выполнить пробный запрос валидации OTP с клиента.
5. Мониторинг: проверить логи на предмет ошибок и тестовых подключений.

Роли и обязанности (короткие чеклисты)

• Системный администратор:
  • Устанавливает и обновляет сервер WiKID.
  • Управляет P12-файлами и бэкапом.
• Сетевой инженер:
  • Настраивает белый список IP, маршрутизацию и firewall.
  • Обеспечивает доступность портов 8388/10389 и других используемых портов.
• Оператор безопасности:
  • Планирует ротацию сертификатов и проверяет журнал событий.

Критерии приёмки

• Протокол wAuth активен и отвечает на запросы по SSL.
• LDAP-модуль настроен, и LDAP-проверка успешно выполняется для тестовой учётной записи.
• Сетевой клиент добавлен, сертификат установлен и тестовое валидационное соединение прошло успешно.
• Логи не содержат критических ошибок и зарегистрированы успешные попытки аутентификации.

Короткий глоссарий

• wAuth — нативный WiKID-протокол по SSL с сертификатной аутентификацией.
• P12 — контейнер сертификата с приватным ключом (PKCS#12).
• LDAP bind — операция аутентификации в LDAP-сервере.

FAQ

Что такое wAuth и зачем он нужен?

wAuth — это собственный защищённый протокол WiKID для коммуникации между сетевыми клиентами и сервером аутентификации. Он использует SSL и сертификаты, чтобы гарантировать подлинность клиента и защитить данные при передаче.

Почему в LDAP_wauth_host обычно используется 127.0.0.1?

Параметр указывает, какой экземпляр WiKID обрабатывает LDAP bind-запросы. В большинстве одностраничных установок WiKID и LDAP работают на одном хосте, поэтому указывается 127.0.0.1. В распределённых системах это следует заменить на адрес соответствующего сервера.

Резюме

Этот документ объяснил, как включать модули протоколов в WiKID, настроить LDAP и создавать сетевые клиенты wAuth с сертификатами. Выполните чеклист администратора и примите рекомендации по безопасности перед вводом в эксплуатацию.