Què passa al pas del navegador d’un inici de sessió federat a la VPN

Feu clic a Connecta i, en lloc d’un camp de contrasenya, el client VPN obre el navegador. Aquest traspàs confon qui espera que el túnel s’autentiqui sol. El navegador no és un desviament: és on el proveïdor d’identitat autentica realment la persona, i el client només espera el resultat.

Recórrer un inici de sessió de principi a fi mostra a quin punt pertany cada fallada, i aquesta és la part que la majoria de runbooks s’estalvien.

Comenceu pel client, no per la configuració de la passarel·la

El client construeix una sol·licitud i envia el navegador al proveïdor d’identitat amb un identificador de proveïdor de serveis i una ubicació de retorn. Després l’IdP de la vostra organització executa el que tingui configurat: contrasenya, MFA, comprovació del dispositiu, accés condicional. Si el navegador ja té una sessió vàlida, la part visible pot dur un segon o dos. Aquesta brevetat és reutilització de sessió, no una comprovació omesa.

Llegiu a la configuració de federació del client dos valors abans de res: les metadades o l’URL de l’IdP en què confia, i l’adreça de retorn que espera. Una discrepància aquí falla abans que es teclegi cap contrasenya.

Què ha de retornar el proveïdor d’identitat

L’IdP respon amb una resposta SAML signada que conté una asserció: qui és el subjecte, qui l’ha emès, per a qui és i quant de temps és vàlida. Aquests camps són el contracte. Emissor, audiència, destinatari i finestra de validesa han de coincidir amb el que espera el servei.

Una resposta signada per l’IdP correcte però adreçada a una altra audiència continua sent invàlida. Aquesta és la comprovació que la gent s’estalvia quan copia metadades d’un laboratori a producció.

Què valida el servei VPN abans de confiar en vós

El servei verifica la signatura amb el certificat de confiança, comprova l’emissor, l’audiència i el destinatari, i després avalua les condicions temporals. Només després mapeja l’asserció a un usuari o grup i aplica la política d’autorització de la VPN. Aquí autenticació i autorització són passos separats, i una asserció vàlida sense cap grup coincident produeix una sessió que connecta i no arriba enlloc.

L’asserció és material d’autenticació, no una contrasenya. Enganxar-la en un altre client, o guardar-la per a una reconnexió posterior, no és un inici de sessió admès.

Dues vides que acaben per separat

La sessió del navegador a l’IdP i la sessió VPN a la passarel·la caduquen amb rellotges diferents. Tancar la sessió de l’IdP no desmunta necessàriament un túnel establert, i desconnectar el túnel no us tanca la sessió del navegador.

AWS Client VPN documenta que el seu flux federat no admet el tancament de sessió únic SAML, que és un exemple concret d’aquest desfasament. Comproveu el vostre servei en lloc de suposar simetria.

Per això una reconnexió es comporta diferent a les 09:00 i a les 15:00. Pot reutilitzar la sessió de l’IdP en silenci, tornar a demanar MFA o fallar perquè la durada de sessió del punt final ha vençut mentre la del navegador no. El flux de federació d’AWS descriu els seus propis requisits de client i de resposta, i altres serveis fan servir traspàsos diferents.

Quan falla el pas del navegador, comproveu-ho en aquest ordre

Treballeu des del navegador cap enfora, perquè el missatge d’error sol nomenar l’últim salt i no el primer.

Si la pàgina no carrega mai, l’URL de l’IdP al client o el camí fins a ella és incorrecte. Si l’IdP rebutja la sol·licitud, l’identificador de proveïdor de serveis o el retorn no coincideixen amb la seva configuració. Si el navegador mostra èxit i el client encara falla, la resposta ha arribat al lloc equivocat o no ha passat la validació d’audiència i temps. I si el túnel puja sense accés, l’asserció s’ha acceptat però el mapatge de grup no.

Tingueu la pàgina esperada, el retorn i el mapatge de grup en un sol document. Així, un usuari que informa d’un inici de sessió VPN trencat pot dir quina d’aquestes quatre coses ha vist, i la resposta ja és mig escrita.