AWS Client VPN SAML и Google Workspace: разрыв в обратном вызове
Google показывает app_not_configured_for_user ещё до появления любого туннеля. Клиент хочет обычный HTTP обратный вызов на loopback, который Workspace не принимает.
Страница app_not_configured_for_user приходит из Google Workspace и появляется раньше, чем согласован хотя бы один пакет туннеля. Этот порядок и есть весь диагноз. Переустановка клиента, правка профиля или проверка маршрутов не уберут страницу, которую конечная точка VPN ещё не видела. Сбойный шаг — это передача в браузере между поставщиком идентичности и слушателем на самой машине пользователя, и в этой передаче стоит проверить ровно три вещи.
Читайте страницу как заявление поставщика идентичности
Google возвращает это, когда приложение SAML не включено для учётной записи, которая вошла. Приложение может быть отключено, пользователь может находиться вне назначенного организационного подразделения или группы, либо настройки поставщика услуг могут не совпадать с тем, что требовал запрос.
Ничто из этого не является проблемой сертификата, маршрута или туннеля, хотя пользователь заметил это именно в клиенте VPN.
Два значения, которые клиент примет
AWS Client VPN выполняет обмен SAML, инициированный поставщиком услуг, поэтому клиент открывает браузер, пользователь аутентифицируется, а поставщик отправляет подписанное утверждение обратно на адрес Assertion Consumer Service. Для настольного клиента, который предоставляет AWS, этот адрес — слушатель на loopback, обычно порт 35001, а ожидаемая аудитория — идентификатор сущности приложения SAML Client VPN, а не сущность входа в консоль AWS.
Оба значения должны совпадать с тем, что ожидает клиент: куда отправляется утверждение и кому оно адресовано. Конфигурация, скопированная из приложения SSO в консоли, может выглядеть совершенно правдоподобно и всё же нацеливаться на неверную пару.
Берите оба значения из требований Client VPN SAML, а не из общего руководства по единому входу AWS. Сущность SSO в консоли выглядит достаточно похоже, чтобы соблазнить. Это другое приложение с другой аудиторией, и клиент отклоняет утверждение, не объясняя себя. Скопируйте пару один раз и храните её рядом с профилем.
Google не примет обратный вызов по обычному HTTP
Консоль администратора требует адрес ACS по HTTPS, а обратный вызов клиента — обычный HTTP на loopback. Это значение вообще нельзя ввести в конфигурацию приложения Workspace, поэтому некоторые команды пробуют обратный прокси, который завершает TLS и передаёт на локальный слушатель. Это не устраняет несоответствие: браузер видит один источник, клиент объявляет другой, и возвращённый ответ может прийти к неверному адресату.
Работающее решение — посреднический поставщик идентичности. Приложение SAML у посредника получает обратный вызов на loopback и аудиторию AWS, а посредник федерарует учётную запись Workspace выше по цепочке. Правило HTTPS у Google остаётся выполненным, и утверждение, доходящее до клиента, по-прежнему называет ожидаемые адрес и аудиторию.
Этот посредник — административная зависимость, которой кто-то должен владеть, которую нужно мониторить и включать в оформление увольнения. Это ещё и второе место, где сбой превращается в ошибку входа. Оцените его, прежде чем обещать такую схему. Если владельца не будет, честный ответ: клиент AWS не может использовать Workspace как единственного поставщика идентичности.
Назначение и двухэтапная проверка
Прежде чем что-либо перепроектировать, убедитесь, что приложение включено для нужного организационного подразделения или группы и что у сторонних приложений SAML есть собственные средства назначения, отдельные от списка приложений на стороне Google.
Проверьте также, включена ли в учётной записи двухэтапная проверка. Google может требовать её до того, как приложение SAML станет доступно пользователю, и один из ответов в исходной ветке решился именно так. Это проще всего исключить и неприятнее всего обнаружить последним.
Проверяйте на чистой сессии
После любого изменения тестируйте с новым профилем браузера и чистой конфигурацией клиента. Кешированные утверждения и переиспользованные сессии скрывают, дошло ли исправление.
Затем сравните две записи рядом: событие аудита поставщика идентичности и журнал клиента. Успешный вход без туннеля указывает обратно на обратный вызов или аудиторию. Подключённый туннель с недоступным ресурсом — это проблема маршрутизации или авторизации, и она относится совсем в другое место.
Что не менять
Не удаляйте auth-federate из профиля и не отключайте проверки сертификатов, чтобы обойти страницу. И то и другое меняет схему аутентификации, а не сбойный обратный вызов, и оба обычно ломаются при следующем обновлении клиента.
Исправьте вместо этого передачу и оставьте заметку, где названы посредник, аудитория и порт loopback. Следующему человеку, который увидит страницу, понадобятся все три.