VPN SSO пайдаланушыларды ішкі қолданбаларға автоматты түрде кіргізе ме?

Сәйкестендіру провайдері арқылы аутентификациялайтын VPN шлюзі бір нәрсені дәлелдейді: провайдер пайдаланушыны шлюз алдында кепілдендірді. Ол бұл пайдаланушыға ішкі желі викиіне, мониторинг тақтасына немесе build-серверге куәлік бермейді. Ол қызметтер адамдарды өз федерациясы арқылы кіргізеді және өз авторизациясын қолданады, ал туннель тек қай пакеттердің оларға жететінін шешеді.

Үш сессия, үш бөлек шешім

Күйлерді бөлек ұстаңыз, өйткені әрқайсысы өз кестесімен аяқталады. VPN сессиясы — шлюздің сәйкестікті қабылдауы және оның берген желілік қатынасы. Сәйкестендіру провайдеріндегі браузер сессиясы — браузердің сол провайдер үшін әлі ұстап тұрғаны және оның саясатына сай қайта пайдалана алатыны. Қолданба сессиясы өзіне арналған жауапты тексерген бір қызметке тиесілі.

Осы күйлерді шатастыру дұрыс емес сұрақ тудырады, әдетте туннель неге пайдаланушыны барлық жерде кіргізбейді деп қойылады. Оны қайта құрыңыз: қай қолданбада федерация жазбасы жоқ, қайсы пайдаланушыны қабылдамайды және қайсында маршрут жетіспейді. Ішкі желі қолданбасын ашатын бір кіру сұранысы бәрібір провайдерге қайта секіруі мүмкін, өйткені екінші қайта бағыттау басқа аудитория үшін жаңа авторизация сұранысы.

Шлюзді өзінің жеке қолданбасы ретінде қосыңыз

VPN-ді провайдерде мақұлданған қолданба ретінде тіркеңіз, оның өз идентификаторы, қайта бағыттау URI және пайдаланушыларды тағайындауымен. Содан кейін бұл кіру қандай желілік авторизациялар беретінін шешіңіз, өйткені бұл VPN саясаты, провайдер функциясы емес. Тек мониторинг қосалқы желісіне жетуі керек пайдаланушылар басқа шлюз саясатын алады, басқа құпиясөзді емес.

Туннельдің аутентификация жауабы қайта пайдалануға болатын куәлік емес. OIDC ID токендері қай клиент үшін шығарылғанын атайтын аудитория мәлімдемесін алып жүреді, ал SAML тасымалдаушы тұжырымдары аудиторияны қабылдаушы қызмет провайдерімен шектейді. Бірінші қызметтің жауабын қабылдайтын екінші қызмет қате конфигурацияланған, ал токенді басқа қолданбаға көшіру интеграция емес.

Әр ішкі қолданбаны тіркеңіз, содан кейін браузер контекстін орнатыңыз

Әр қызметке қолдау көрсетілетін SAML немесе OIDC мәндері қажет: шығарушы, клиент идентификаторы, кері шақыру немесе тұжырымды тұтынушы URL, қажетті мәлімдемелер және тағайындау. Қолжетімділік оның үстіне қосылады, өйткені сәйкестік тексерулері ешқашан маршрут немесе DNS жауабын бермейді.

1. Қолданба жазбасын жасаңыз және субъект немесе клиент ID қолданба жіберетінмен сәйкес келетінін растаңыз.
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 профилі емес.

Сұраныстарды кім сұрағанын тауып түзетіңіз

Екінші құпиясөз сұранысы автоматты түрде ақау емес. Қолданба жоғарырақ кепілдік деңгейін сұрауы мүмкін, немесе провайдер сессияның ең үлкен жасын және жаңа сынақты талап етуі мүмкін. Ағымды тыныштау үшін бұл талаптарды алып тастау әдейі қойылған бақылауды әлсіретеді, сондықтан саясатты өзгерту алдында қай құрамдас сұрағанын анықтаңыз.

Содан кейін нені жақсарту керегін шешіңіз. Сұраныс қолданбадан келсе, оның федерация жазбасын түзетіңіз. Саясат бойынша провайдерден келсе, талапты құжаттаңыз. Сәтті кіруден кейін қолданбаға жету мүмкін болмаса, күдікті — туннельдің маршруттауы, өйткені сәйкестік пен пакеттерді жеткізу әртүрлі жерлерде сәтсіз аяқталады және пайдаланушы орнынан ұқсас көрінеді.