Awtomatiko bang nag-sign in ang VPN SSO sa mga internal na app?

Ang VPN gateway na nagpapatotoo sa pamamagitan ng identity provider ay nagpapatunay ng isang bagay: ginagarantiya ng provider ang isang user sa harap ng gateway. Hindi nito binibigyan ang user na iyon ng kredensyal para sa wiki ng intranet, monitoring dashboard o build server. Ang mga serbisyong iyon ay nagpapa-sign in sa mga tao sa pamamagitan ng sarili nilang federation at naglalapat ng sarili nilang awtorisasyon, at ang tunnel lamang ang nagpapasya kung aling mga packet ang makakaabot sa kanila.

Tatlong session, tatlong hiwalay na desisyon

Panatilihing hiwalay ang mga estado, dahil ang bawat isa ay nag-expire sa sarili nitong iskedyul. Ang session ng VPN ay ang pagtanggap ng gateway sa isang pagkakakilanlan at ang network access na ibinigay nito. Ang session ng browser sa identity provider ay ang hawak pa ng browser para sa provider na iyon at maaaring muling gamitin ayon sa patakaran nito. Ang session ng app ay pag-aari ng isang serbisyo na nagpatunay ng tugon na nakakabit dito.

Ang paghahalo ng mga estadong ito ay nagdudulot ng maling tanong, kadalasang binabalangkas bilang bakit hindi nag-sign in ang tunnel sa user sa lahat ng lugar. Isalit muli ito: aling app ang walang entry sa federation, alin ang tumatanggi sa user, at alin ang kulang sa ruta. Ang isang prompt ng pag-sign in na nagbubukas ng intranet app ay maaari pa ring tumalbog pabalik sa provider, dahil ang ikalawang redirect ay bagong kahilingan ng awtorisasyon para sa ibang audience.

Ikonekta ang gateway bilang sarili nitong app

Irehistro ang VPN bilang aprubadong app sa provider, kasama ang sariling identifier, redirect URI at pagtatalaga ng user. Pagkatapos ay magpasya kung aling mga awtorisasyon ng network ang ibinibigay ng pag-sign in na iyon, dahil patakaran ito ng VPN at hindi tampok ng provider. Ang mga user na dapat umabot lamang sa monitoring subnet ay tumatanggap ng ibang patakaran ng gateway, hindi ibang password.

Ang tugon ng pagpapatotoo ng tunnel ay hindi muling magagamit na kredensyal. Ang mga token ng ID ng OIDC ay may claim ng audience na nagngangalan sa client kung kanino ibinigay ang mga ito, at ang mga bearer assertion ng SAML ay nililimitahan ang audience sa tumatanggap na service provider. Ang ikalawang serbisyo na tumatanggap ng tugon ng una ay mali ang pagkaka-configure, at ang pagkopya ng token sa ibang app ay hindi integrasyon.

Irehistro ang bawat internal na app, pagkatapos ay itakda ang konteksto ng browser

Kailangan ng bawat serbisyo ang sinusuportahang halaga ng SAML o OIDC: issuer, identifier ng client, URL ng callback o consumer ng assertion, mga kinakailangang claim at pagtatalaga. Ang pagiging maabot ay dumarating sa ibabaw, dahil ang mga pagsusuri ng pagkakakilanlan ay hindi kailanman nagbibigay ng ruta o sagot ng DNS.

1. Gumawa ng entry ng app at kumpirmahin na tumutugma ang ID ng entity o client sa ipinapadala ng app.
2. Irehistro ang eksaktong URL ng callback kasama ang scheme at port; ang maliit na pagkakamali ay nabibigo pagkatapos magpatotoo ng user.
3. Itakda ang mga user o grupo, pagkatapos ay kumpirmahin na inilalabas ang mga kinakailangang claim.
4. Payagan ang mga endpoint ng identity provider gayundin ang pribadong app, kung hindi ay hindi makukumpleto ang redirect.

Ang konteksto ng browser ang nagpapasya kung muling gagamitin ang umiiral na session ng provider. Ang native client na nagbubukas ng system browser ay maaaring magbahagi ng estadong iyon, samantalang ang naka-embed na view na may sariling cookie jar ay kadalasang hindi. Bagong browser, mga pribadong window at ikalawang profile ay nagsisimula sa wala, na inaasahan at hindi sirang configuration ng SSO.

Patakbuhin ang daloy at basahin kung saan ito humihinto

Kopyahin gamit ang network panel ng browser at panoorin ang kadena ng redirect. Ang kapaki-pakinabang na paglalakbay ay sumusunod sa isang pagtalon sa isang pagkakataon: gateway patungo sa provider, provider pabalik sa app na may code o assertion, app patungo sa token endpoint ng provider, inilabas ang session ng app. Ang pagtalon kung saan humihinto ang kadena ang nagngangalan sa komponenteng dapat ayusin.

Dalawang pagsusuri sa command line ang nagtatanggal ng karaniwang pagdududa, at pareho ay ligtas na patakbuhin mula sa admin host:

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:)'

Kapag naglista ang metadata ng mga endpoint na hindi mo kailanman nairehistro, ang app ay tumuturo sa ibang tenant o issuer. Kapag ang unang kahilingan sa app ay sumagot ng 302 patungo sa hindi inaasahang host, ang configuration ng federation ng app ang lugar na titingnan, hindi ang profile ng VPN.

Ayusin ang mga prompt sa pamamagitan ng paghahanap kung sino ang humiling

Ang ikalawang prompt ng password ay hindi awtomatikong depekto. Maaaring humiling ang app ng mas mataas na antas ng katiyakan, o maaaring ipatupad ng provider ang maximum na edad ng session at bagong hamon. Ang pag-alis ng mga kinakailangang iyon para maging tahimik ang daloy ay nagpapahina sa sadyang kontrol, kaya tukuyin kung aling komponent ang humiling bago baguhin ang patakaran.

Pagkatapos ay magpasya kung ano ang pagbutihin. Kung ang prompt ay mula sa app, ayusin ang entry nito sa federation. Kung mula sa provider ayon sa patakaran, idokumento ang kinakailangan. Kung hindi maabot ang app pagkatapos ng matagumpay na pag-sign in, ang routing ng tunnel ang pinaghihinalaan, dahil ang pagkakakilanlan at paghahatid ng packet ay nabibigo sa iba't ibang lugar at magkamukha mula sa upuan ng user.