Што адбываецца на этапе браўзера пры федэратыўным уваходзе ў VPN

Вы націскаеце «Падключыцца», і замест поля пароля кліент VPN адкрывае браўзер. Такая перадача бянтэжыць тых, хто чакае, што тунель аўтэнтыфікуе сябе сам. Браўзер — не аб'езд: менавіта там пастаўшчык ідэнтычнасці сапраўды аўтэнтыфікуе чалавека, а кліент толькі чакае выніку.

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

Пачынайце з кліента, а не з наладаў шлюза

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

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

Што павінен вярнуць пастаўшчык ідэнтычнасці

IdP адказвае подпісаным адказам SAML з сцвярджэннем: хто суб'ект, хто выдаў, для каго прызначана і колькі дзейнічае. Гэтыя палі — дамова. Выдавец, аўдыторыя, атрымальнік і акно дзейнасці павінны супадаць з тым, што чакае служба.

Адказ, подпісаны правільным IdP, але адрасаваны іншай аўдыторыі, усё роўна несапраўдны. Менавіта гэтую праверку прапускаюць, калі капіруюць метаданыя з лабараторыі ў прадукцыю.

Што служба VPN правярае, перш чым давяраць вам

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

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

Два тэрміны, якія сканчаюцца асобна

Сеанс браўзера ў IdP і сеанс VPN на шлюзе сканчаюцца ў розныя моманты. Выхад з IdP не абавязкова разрывае ўсталяваны тунель, а адключэнне тунеля не выводзіць вас з браўзера.

AWS Client VPN дакументуе, што яго федэратыўны паток не падтрымлівае адзіны выхад SAML, і гэта канкрэтны прыклад такой розніцы. Правярайце сваю службу, а не мяркуйце сіметрыю.

Таму перападключэнне паводзіць сябе інакш у 09:00 і ў 15:00. Яно можа моўчкі паўторна выкарыстаць сеанс IdP, зноў запытаць MFA або скончыцца збоем, бо тэрмін сеансу канчатковай кропкі скончыўся, а сеанс браўзера не. Працоўны паток федэрацыі AWS апісвае свае патрабаванні да кліента і адказу, а іншыя службы выкарыстоўваюць іншыя перадачы.

Калі этап браўзера не ўдаецца, правярайце ў такім парадку

Ідзіце ад браўзера вонкі, бо паведамленне пра памылку звычайна называе апошні крок, а не першы.

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

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