L'SSO de VPN inicia la sessió dels usuaris a les aplicacions internes automàticament?

Una passarel·la VPN que s'autentica mitjançant un proveïdor d'identitat demostra una cosa: que el proveïdor ha avalat un usuari davant la passarel·la. No lliura a aquest usuari cap credencial per al wiki de la intranet, el tauler de monitoratge o el servidor de compilació. Aquests serveis inicien la sessió de les persones mitjançant la seva pròpia federació i apliquen la seva pròpia autorització, i el túnel només decideix quins paquets poden arribar-hi.

Tres sessions, tres decisions separades

Manteniu els estats separats, perquè cadascun caduca segons el seu propi calendari. La sessió VPN és l'acceptació d'una identitat per part de la passarel·la més l'accés de xarxa que ha concedit. La sessió del navegador al proveïdor d'identitat és el que el navegador encara conserva per a aquest proveïdor i pot reutilitzar segons la seva política. La sessió de l'aplicació pertany a un servei que ha validat una resposta adreçada a ell.

Confondre aquests estats produeix la pregunta equivocada, normalment formulada com per què el túnel no inicia la sessió de l'usuari a tot arreu. Reformuleu-la: quina aplicació no té entrada de federació, quina rebutja l'usuari i quina no té ruta. Un sol avís d'inici de sessió que obre l'aplicació d'intranet encara pot rebotar cap al proveïdor, perquè la segona redirecció és una nova sol·licitud d'autorització per a una audiència diferent.

Connecteu la passarel·la com a aplicació pròpia

Registreu la VPN com a aplicació aprovada al proveïdor, amb el seu propi identificador, URI de redirecció i assignació d'usuaris. Després decidiu quines autoritzacions de xarxa concedeix aquest inici de sessió, ja que és una política de VPN i no una funció del proveïdor. Els usuaris que només han d'arribar a la subxarxa de monitoratge reben una política de passarel·la diferent, no una contrasenya diferent.

La resposta d'autenticació del túnel no és una credencial reutilitzable. Els testimonis d'ID OIDC porten una declaració d'audiència que anomena el client per al qual es van emetre, i les assercions portadores SAML restringeixen l'audiència al proveïdor de servei receptor. Un segon servei que accepta la resposta del primer està mal configurat, i copiar un testimoni a una altra aplicació no és integració.

Registreu cada aplicació interna i després configureu el context del navegador

Cada servei necessita els valors SAML o OIDC admesos: emissor, identificador de client, URL de retorn de trucada o de consumidor d'assercions, declaracions requerides i assignació. L'accessibilitat ve a sobre, perquè les comprovacions d'identitat no forneixen mai una ruta ni una resposta DNS.

1. Creeu l'entrada de l'aplicació i confirmeu que l'ID d'entitat o de client coincideix amb el que envia l'aplicació.
2. Registreu l'URL exacte de retorn de trucada, incloent l'esquema i el port; un error mínim falla després que l'usuari s'autentiqui.
3. Assigneu els usuaris o grups i confirmeu que les declaracions requerides s'emeten.
4. Permeteu els punts finals del proveïdor d'identitat així com l'aplicació privada, o la redirecció no es podrà completar.

El context del navegador decideix si es reutilitza una sessió existent del proveïdor. Un client natiu que obre el navegador del sistema pot compartir aquest estat, mentre que una vista incrustada amb la seva pròpia cistella de galetes normalment no pot. Un navegador nou, les finestres privades i un segon perfil comencen de zero, cosa que és esperable i no una configuració SSO trencada.

Executeu el flux i llegiu on s'atura

Reproduïu-ho amb el tauler de xarxa del navegador i observeu la cadena de redireccions. Un recorregut útil segueix un salt alhora: de la passarel·la al proveïdor, del proveïdor de tornada a l'aplicació amb un codi o una asserció, de l'aplicació al punt final de testimonis del proveïdor, i la sessió de l'aplicació emesa. El salt on s'atura la cadena anomena el component que cal corregir.

Dues comprovacions de línia d'ordres resolen els dubtes habituals, i totes dues es poden executar sense risc des d'un amfitrió d'administració:

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

Quan les metadades llisten punts finals que mai no heu registrat, l'aplicació apunta a un altre inquilí o emissor. Quan la primera sol·licitud a l'aplicació respon 302 cap a un amfitrió inesperat, la configuració de federació de l'aplicació és el lloc on cal mirar, no el perfil de VPN.

Corregiu els avisos trobant qui els ha demanat

Un segon avís de contrasenya no és automàticament un defecte. L'aplicació pot demanar un nivell de garantia més alt, o bé el proveïdor pot imposar una edat màxima de sessió i un repte nou. Eliminar aquests requisits per fer el flux més silenciós debilita un control deliberat, així que establiu quin component ho ha demanat abans de canviar la política.

Després decidiu què millorar. Si l'avís ve de l'aplicació, corregiu la seva entrada de federació. Si ve del proveïdor per política, documenteu el requisit. Si l'aplicació no és accessible després d'un inici de sessió correcte, l'encaminament del túnel és el sospitós, perquè la identitat i el lliurament de paquets fallen en llocs diferents i semblen similars des del seient de l'usuari.