Що відбувається на етапі браузера під час федеративного входу у 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, зможе сказати, що саме з цих чотирьох він побачив, і відповідь уже наполовину готова.