Ці ўваходзіць карыстальнік праз VPN SSO аўтаматычна ва ўнутраныя праграмы?

Шлюз VPN, які праходзіць аўтэнтыфікацыю праз пастаўшчыка ідэнтычнасці, даказвае адно: пастаўшчык паручыўся за карыстальніка перад шлюзам. Ён не выдае гэтаму карыстальніку пасведчанне для ўнутранай вікі, панэлі маніторынгу або сервера зборкі. Гэтыя службы ўводзяць людзей праз уласную федэрацыю і ўжываюць уласную аўтарызацыю, а тунель толькі вырашае, якія пакеты могуць да іх дайсці.

Тры сеансы, тры асобныя рашэнні

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

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

Падключыце шлюз як уласную праграму

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

Адказ аўтэнтыфікацыі тунеля не з'яўляецца паўторна выкарыстоўваным пасведчаннем. Маркеры OIDC ID нясуць прэтэнзію аўдыторыі з назвай кліента, для якога яны створаны, а 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.

Выпраўляйце запыты, знайшоўшы, хто іх запытаў

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

Затым вырашыце, што палепшыць. Калі запыт ідзе ад праграмы, выпраўце яе запіс федэрацыі. Калі ад пастаўшчыка па палітыцы, задакументуйце патрабаванне. Калі праграма недасягальная пасля паспяховага ўваходу, падазроная маршрутызацыя тунеля, бо ідэнтычнасць і дастаўка пакетаў церпяць няўдачу ў розных месцах і выглядаюць падобна з месца карыстальніка.