Kio okazas en la retuma paŝo de federacia VPN-ensaluto

Vi klakas Konekti, kaj anstataŭ pasvortujo la VPN-kliento malfermas vian retumilon. Tiu transdono konfuzas homojn, kiuj atendas, ke la tunelo mem aŭtentikigos sin. La retumilo ne estas flankvojo: ĝuste tie la identecprovizanto vere aŭtentikigas la personon, kaj la kliento nur atendas la rezulton.

Sekvi unu ensaluton de komenco ĝis fino montras, al kiu paŝo apartenas ĉiu fiasko, kaj ĝuste tiun parton la plej multaj runlibroj preterlasas.

Komencu ĉe la kliento, ne ĉe la pordega agordo

La kliento konstruas peton kaj sendas la retumilon al la identecprovizanto kun identigilo de servo-provizanto kaj revena loko. Poste la IdP de via organizo plenumas tion, kio estas agordita: pasvorto, MFA, aparata kontrolo, kondiĉa aliro. Se la retumilo jam havas validan sesion, la videbla parto povas daŭri unu aŭ du sekundojn. Tiu mallongeco estas reuzo de sesio, ne preterlasita kontrolo.

Legu en la federacia agordo de la kliento du valorojn antaŭ ĉio alia: la IdP-metadatumojn aŭ URL-on, kiun ĝi fidas, kaj la revokadreson, kiun ĝi atendas. Miskongruo tie fiaskas antaŭ ol iu pasvorto estas tajpita.

Kion la identecprovizanto devas redoni

La IdP respondas per subskribita SAML-respondo enhavanta aserton: kiu estas la subjekto, kiu ĝin eldonis, por kiu ĝi estas kaj kiom longe ĝi validas. Tiuj kampoj estas la kontrakto. Eldoninto, publiko, ricevanto kaj valideca fenestro devas ĉiuj kongrui kun tio, kion la servo atendas.

Respondo subskribita de la ĝusta IdP sed adresita al alia publiko restas nevalida. Tion homoj preterlasas, kiam ili kopias metadatumojn de laboratorio al produktaĵo.

Kion la VPN-servo validigas antaŭ ol fidi vin

La servo kontrolas la subskribon kontraŭ la fidata atestilo, kontrolas la eldoninton, la publikon kaj la ricevanton, poste taksas la tempajn kondiĉojn. Nur poste ĝi mapas la aserton al uzanto aŭ grupo kaj aplikas la VPN-rajtigan politikon. Aŭtentikigo kaj rajtigo estas ĉi tie apartaj paŝoj, kaj valida aserto sen kongrua grupo donas sesion, kiu konektiĝas kaj atingas nenion.

La aserto estas aŭtentikiga materialo, ne pasvorto. Enmeti ĝin en alian klienton aŭ konservi ĝin por posta rekonekto ne estas subtenata ensaluto.

Du daŭroj, kiuj finiĝas aparte

La retuma sesio ĉe la IdP kaj la VPN-sesio ĉe la pordego eksvalidiĝas laŭ malsamaj horloĝoj. Elsaluti ĉe la IdP ne nepre disfaligas establitan tunnelon, kaj malkonekti la tunnelon ne elsalutas vin el la retumilo.

AWS Client VPN dokumentas, ke ĝia federacia fluo ne subtenas unuopan SAML-elsaluton, kio estas konkreta ekzemplo de tiu manko. Kontrolu vian propran servon anstataŭ supozi simetrion.

Tial rekonekto kondutas malsame je 09:00 kaj je 15:00. Ĝi povas silente reuzi la IdP-sesion, denove peti MFA aŭ fiaski ĉar la daŭro de la finpunkta sesio eksvalidiĝis dum tiu de la retumilo ne. La AWS-federacia laborfluo priskribas siajn proprajn postulojn pri kliento kaj respondo, kaj aliaj servoj uzas malsamajn transdonojn.

Kiam la retuma paŝo fiaskas, kontrolu ĉi tion laŭ ordo

Laboru de la retumilo eksteren, ĉar la erarmesaĝo kutime nomas la lastan salton, ne la unuan.

Se la paĝo neniam ŝarĝiĝas, la IdP-URL de la kliento aŭ la vojo al ĝi estas malĝusta. Se la IdP rifuzas la peton, la identigilo de servo-provizanto aŭ la revokado ne kongruas kun ĝia agordo. Se la retumilo montras sukceson kaj la kliento tamen fiaskas, la respondo alvenis al la malĝusta loko aŭ malsukcesis en publika kaj tempa validigado. Kaj se la tunelo leviĝas sen aliro, la aserto estis akceptita sed la grupa mapado ne.

Tenu la atendatan paĝon, la revokadon kaj la grupan mapadon en unu dokumento. Tiam uzanto, kiu raportas rompitan VPN-ensaluton, povas diri, kiun el tiuj kvar aferoj li vidis, kaj la respondo jam estas duone skribita.