Автоматически ли VPN SSO выполняет вход пользователей во внутренние приложения?

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

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

Три сеанса, три отдельных решения

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

Смешение этих состояний порождает неверный вопрос, обычно звучащий как почему туннель не выполняет вход пользователя везде. Переформулируйте: у какого приложения нет записи федерации, какое отклоняет пользователя и какому не хватает маршрута. Один запрос входа, открывающий приложение внутренней сети, всё равно может вернуться к поставщику, потому что второе перенаправление — это новый запрос авторизации для другой аудитории.

Подключите шлюз как отдельное приложение

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

Ответ аутентификации туннеля не является многоразовыми учётными данными. Токены ID OIDC содержат утверждение аудитории, называющее клиента, для которого они выпущены, а утверждения-носители SAML ограничивают аудиторию принимающим поставщиком услуг. Вторая служба, принимающая ответ первой, настроена неверно, а копирование токена в другое приложение не является интеграцией.

Зарегистрируйте каждое внутреннее приложение, затем настройте контекст браузера

Каждой службе нужны поддерживаемые значения SAML или OIDC: издатель, идентификатор клиента, URL обратного вызова или потребителя утверждений, требуемые утверждения и назначение. Доступность добавляется сверху, потому что проверки удостоверений никогда не предоставляют маршрут или ответ DNS.

  1. Создайте запись приложения и подтвердите, что идентификатор сущности или клиента совпадает с тем, что отправляет приложение.
  2. Зарегистрируйте точный URL обратного вызова, включая схему и порт; небольшая ошибка приводит к сбою после аутентификации пользователя.
  3. Назначьте пользователей или группы, затем подтвердите, что требуемые утверждения выдаются.
  4. Разрешите конечные точки поставщика удостоверений и частное приложение, иначе перенаправление не завершится.

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

Запустите поток и прочитайте, где он останавливается

Воспроизведите с панелью сети браузера и наблюдайте за цепочкой перенаправлений. Полезный проход следует по одному переходу: от шлюза к поставщику, от поставщика обратно в приложение с кодом или утверждением, от приложения к конечной точке токенов поставщика, сеанс приложения выдан. Переход, на котором цепочка останавливается, называет компонент для исправления.

Две проверки из командной строки разрешают обычные сомнения, и обе безопасно выполнять с административного хоста:

curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.authorization_endpoint, .token_endpoint'
curl -sI https://app.example.net/ | grep -iE '^(HTTP/|location:)'

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

Исправляйте запросы, выясняя, кто их запросил

Второй запрос пароля не является автоматически дефектом. Приложение может требовать более высокого уровня гарантии, или поставщик может навязывать максимальный возраст сеанса и новую проверку. Удаление этих требований, чтобы поток стал тише, ослабляет намеренный контроль, поэтому сначала выясните, какой компонент их запросил.

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

Похожие статьи