Что происходит на этапе браузера при федеративном входе в VPN

Вы нажимаете «Подключиться», и вместо поля пароля VPN-клиент открывает ваш браузер. Эта передача сбивает с толку тех, кто ожидает, что туннель аутентифицирует себя сам. Браузер — не обходной путь: именно там поставщик идентификации действительно аутентифицирует человека, а клиент лишь ждёт результата.

Если пройти один вход от начала до конца, видно, к какому этапу относится каждая ошибка, и именно эту часть большинство runbook-ов пропускает.

Начинайте с клиента, а не с конфигурации шлюза

Клиент формирует запрос и отправляет браузер к поставщику идентификации с идентификатором поставщика услуг и адресом возврата. Затем IdP вашей организации выполняет то, что настроено: пароль, MFA, проверку устройства, условный доступ. Если у браузера уже есть действующая сессия, видимая часть может занять секунду-другую. Эта краткость — повторное использование сессии, а не пропущенная проверка.

Прежде всего прочитайте в конфигурации федерации клиента два значения: метаданные или URL IdP, которому он доверяет, и адрес обратного вызова, которого он ожидает. Несовпадение там приводит к отказу ещё до ввода пароля.

Что должен вернуть поставщик идентификации

IdP отвечает подписанным ответом SAML, содержащим assertion: кто субъект, кто его выпустил, для кого он предназначен и как долго остаётся действительным. Эти поля и есть контракт. Издатель, audience, получатель и окно действия должны совпадать с тем, что ожидает сервис.

Ответ, подписанный правильным IdP, но адресованный другой audience, всё равно недействителен. Именно эту проверку пропускают, когда копируют метаданные из лаборатории в продакшен.

Что сервис VPN проверяет, прежде чем доверять вам

Сервис проверяет подпись по доверенному сертификату, проверяет издателя, audience и получателя, а затем оценивает временные условия. И только после этого он сопоставляет assertion с пользователем или группой и применяет политику авторизации VPN. Здесь аутентификация и авторизация — отдельные шаги, и действительный assertion без подходящей группы даёт сессию, которая подключается и никуда не попадает.

Assertion — это материал аутентификации, а не пароль. Вставлять его в другой клиент или сохранять для повторного подключения позже — не поддерживаемый вход.

Два срока жизни, которые заканчиваются по отдельности

Сессия браузера у IdP и сессия VPN на шлюзе истекают по разным часам. Выход из IdP не обязательно разрывает установленный туннель, а отключение туннеля не завершает сеанс в браузере.

AWS Client VPN указывает, что его федеративный поток не поддерживает SAML single logout, и это один конкретный пример такого разрыва. Проверяйте собственный сервис, а не предполагайте симметрию.

Поэтому повторное подключение ведёт себя по-разному в 09:00 и в 15:00. Оно может незаметно переиспользовать сессию IdP, снова запросить MFA или завершиться ошибкой, потому что срок сессии конечной точки истёк, а сессия браузера — нет. Рабочий процесс федерации AWS описывает собственные требования к клиенту и ответу, а другие сервисы используют иные способы передачи.

Если этап браузера не сработал, проверяйте в этом порядке

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

Если страница вообще не загружается, URL IdP у клиента или путь к нему неверен. Если IdP отклоняет запрос, идентификатор поставщика услуг или адрес обратного вызова не совпадает с его конфигурацией. Если браузер показывает успех, а клиент всё равно терпит неудачу, ответ попал не туда либо не прошёл проверку audience и времени. А если туннель поднимается без доступа, assertion был принят, а сопоставление групп — нет.

Держите ожидаемую страницу, адрес обратного вызова и сопоставление групп в одном документе. Тогда пользователь, сообщающий о сломанном входе в VPN, сможет сказать, какое из этих четырёх он увидел, и ответ уже наполовину готов.