Чи автоматично 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.

Виправляйте запити, з'ясовуючи, хто їх запитав

Другий запит пароля не є автоматично дефектом. Застосунок може вимагати вищого рівня гарантії, або постачальник може нав'язувати максимальний вік сесії та новий виклик. Вилучення цих вимог, щоб потік став тихішим, послаблює навмисний контроль, тому спершу з'ясуйте, який компонент їх зажадав.

Потім вирішіть, що покращити. Якщо запит іде від застосунку, виправте його запис федерації. Якщо він іде від постачальника за політикою, задокументуйте вимогу. Якщо застосунок недоступний після успішного входу, підозрюваний — маршрутизація тунелю, бо ідентичність і доставка пакетів зазнають збоїв у різних місцях і виглядають однаково з місця користувача.