Влизат ли потребителите автоматично във вътрешните приложения чрез VPN SSO?

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

VPN шлюз, който се удостоверява чрез доставчик на идентичност, доказва едно нещо: доставчикът е гарантирал за потребител пред шлюза. Той не дава на този потребител удостоверение за вътрешното уики, таблото за мониторинг или сървъра за сборки. Тези услуги вписват хората чрез собствената си федерация и прилагат собствена авторизация, а тунелът само решава кои пакети могат да ги достигнат.

Три сесии, три отделни решения

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

Объркването на тези състояния поражда грешния въпрос, обикновено формулиран като защо тунелът не вписва потребителя навсякъде. Преформулирайте: кое приложение няма запис за федерация, кое отказва потребителя и кое няма маршрут. Единична подкана за влизане, която отваря вътрешното приложение, все още може да се върне към доставчика, защото второто пренасочване е ново искане за авторизация за различна аудитория.

Свържете шлюза като самостоятелно приложение

Регистрирайте VPN като одобрено приложение при доставчика, със собствен идентификатор, URI за пренасочване и назначение на потребители. След това решете какви мрежови авторизации дава това влизане, тъй като това е политика на VPN, а не функция на доставчика. Потребителите, които трябва да достигат само подмрежата за мониторинг, получават друга политика на шлюза, а не друга парола.

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

Регистрирайте всяко вътрешно приложение, после настройте контекста на браузъра

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

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

Контекстът на браузъра решава дали съществуваща сесия на доставчика ще бъде използвана повторно. Нативно приложение, което отваря системния браузър, може да сподели това състояние, докато вграденият изглед със собствена кошница за бисквитки обикновено не може. Нов браузър, частни прозорци и втори профил започват от нищо, което е очаквано, а не счупена конфигурация на 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.

Поправяйте подканите, като откриете кой ги поиска

Втора подкана за парола не е автоматично дефект. Приложението може да поиска по-високо ниво на увереност, или доставчикът може да наложи максимална възраст на сесията и ново предизвикателство. Премахването на тези изисквания, за да стане потокът по-тих, отслабва съзнателно поставен контрол, затова установете кой компонент ги е поискал, преди да промените политиката.

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

Подобни статии