Kinachotokea katika hatua ya kivinjari cha kuingia VPN kwa shirikisho

Unabonyeza Unganisha, na badala ya kisanduku cha nenosiri mteja wa VPN hufungua kivinjari chako. Uhamishaji huo huwachanganya watu wanaotarajia handaki ijithibitishe yenyewe. Kivinjari si mchepuko: ni pale mtoa huduma ya utambulisho anapomthibitisha mtu kwa kweli, na mteja anasubiri tu matokeo.

Kupitia uingiaji mmoja mwanzo hadi mwisho kunaonyesha kila hitilafu inapaswa kuwekwa wapi, na ndiyo sehemu ambayo runbook nyingi huiruka.

Anza kwa mteja, si kwa usanidi wa lango

Mteja huunda ombi na humtuma kivinjari kwa mtoa huduma ya utambulisho pamoja na kitambulisho cha mtoa huduma na mahali pa kurudi. Kisha IdP ya shirika lako hufanya kile ilichosanidiwa: nenosiri, MFA, ukaguzi wa kifaa, ufikiaji wa masharti. Ikiwa kivinjari tayari kina kikao halali, sehemu inayoonekana inaweza kuchukua sekunde moja au mbili. Ufupi huo ni kutumia kikao tena, si ukaguzi uliorukwa.

Soma katika usanidi wa shirikisho wa mteja thamani mbili kabla ya kitu kingine chochote: metadata ya IdP au URL anayoiamini, na anwani ya callback anayoitazamia. Kutokulingana hapo hushindwa kabla nenosiri lolote kuandikwa.

Mtoa huduma ya utambulisho anapaswa kurudisha nini

IdP hujibu kwa jibu la SAML lililosainiwa lenye assertion: somo ni nani, ni nani aliyelitoa, ni kwa ajili ya nani, na linabaki halali kwa muda gani. Sehemu hizo ni mkataba. Mtoaji, audience, mpokeaji na dirisha la uhalali lazima vyote vililingane na kile huduma inatarajia.

Jibu lililosainiwa na IdP sahihi lakini lililoelekezwa kwa audience nyingine bado si halali. Huo ni ukaguzi ambao watu huuruka wanapokili metadata kati ya maabara na uzalishaji.

Huduma ya VPN huthibitisha nini kabla ya kukuamini

Huduma huthibitisha sahihi dhidi ya cheti kinachoaminika, hukagua mtoaji, audience na mpokeaji, kisha hutathmini masharti ya muda. Ni baada ya hapo tu ndipo huweka assertion kwa mtumiaji au kikundi na kutumia sera ya idhini ya VPN. Hapa uthibitishaji na idhini ni hatua tofauti, na assertion halali bila kikundi kinacholingana hutoa kikao kinachounganisha na hakifikii chochote.

Assertion ni nyenzo ya uthibitishaji, si nenosiri. Kuibandika kwenye mteja mwingine, au kuihifadhi kwa muunganisho wa baadaye, si kuingia kunakotumika.

Maisha mawili yanayoisha kwa kutengana

Kikao cha kivinjari kwa IdP na kikao cha VPN kwenye lango huisha kwa saa tofauti. Kutoka kwenye IdP hakuharibu handaki lililoanzishwa kila mara, na kukata handaki hakukutoa kwenye kivinjari.

AWS Client VPN inaeleza kwamba mtiririko wake wa shirikisho hautumii SAML single logout, jambo ambalo ni mfano mmoja halisi wa pengo hilo. Kagua huduma yako mwenyewe badala ya kudhani ulinganifu.

Ndiyo sababu muunganisho upya hujiendesha tofauti saa 09:00 na saa 15:00. Unaweza kutumia kikao cha IdP kimya kimya, kuomba MFA tena, au kushindwa kwa sababu muda wa kikao cha endpoint uliisha wakati ule wa kivinjari haukuisha. Mtiririko wa shirikisho wa AWS unaeleza mahitaji yake ya mteja na jibu, na huduma nyingine hutumia uhamishaji tofauti.

Hatua ya kivinjari inaposhindwa, kagua hizi kwa mpangilio

Fanya kazi kutoka kivinjari kwenda nje, kwa sababu ujumbe wa hitilafu kawaida hutaja hatua ya mwisho badala ya ya kwanza.

Ikiwa ukurasa haupakiwi kamwe, URL ya IdP ya mteja au njia ya kuifikia si sahihi. Ikiwa IdP inakataa ombi, kitambulisho cha mtoa huduma au callback hailingani na usanidi wake. Ikiwa kivinjari kinaonyesha mafanikio na mteja bado anashindwa, jibu lilifika mahali pabaya au lilishindwa uthibitishaji wa audience na muda. Na ikiwa handaki linatokea bila ufikiaji, assertion ilikubaliwa lakini uchoraji wa vikundi haukukubaliwa.

Weka ukurasa unaotarajiwa, callback na uchoraji wa vikundi katika hati moja. Ndipo mtumiaji anayeripoti kuingia VPN kuvunjika anaweza kusema ni kipi kati ya vitu hivyo vinne alivyoona, na jibu tayari limeandikwa nusu.