O SSO de VPN inicia a sesión dos usuarios nas aplicacións internas automaticamente?

Unha pasarela VPN que se autentica mediante un provedor de identidade demostra unha cousa: o provedor respondeu por un usuario ante a pasarela. Non lle entrega a ese usuario unha credencial para o wiki da intranet, o panel de monitorización ou o servidor de compilación. Eses servizos inician a sesión das persoas mediante a súa propia federación e aplican a súa propia autorización, e o túnel só decide que paquetes poden chegar a eles.

Tres sesións, tres decisións separadas

Manteña os estados separados, porque cada un caduca segundo o seu propio calendario. A sesión VPN é a aceptación dunha identidade pola pasarela máis o acceso de rede que concedeu. A sesión do navegador no provedor de identidade é o que o navegador aínda conserva para ese provedor e pode reutilizar segundo a súa política. A sesión da aplicación pertence a un servizo que validou unha resposta dirixida a el.

Confundir eses estados produce a pregunta equivocada, normalmente formulada como por que o túnel non inicia a sesión do usuario en todas partes. Reformúlea: que aplicación non ten entrada de federación, cal rexeita o usuario e a cal lle falta unha ruta. Un único aviso de inicio de sesión que abre a aplicación da intranet aínda pode rebotar ao provedor, porque a segunda redirección é unha nova solicitude de autorización para unha audiencia distinta.

Conecte a pasarela como a súa propia aplicación

Rexiste a VPN como unha aplicación aprobada no provedor, co seu propio identificador, URI de redirección e asignación de usuarios. Logo decida que autorizacións de rede concede ese inicio de sesión, xa que é unha política de VPN e non unha función do provedor. Os usuarios que só deben chegar á subrede de monitorización reciben unha política de pasarela distinta, non un contrasinal distinto.

A resposta de autenticación do túnel non é unha credencial reutilizable. Os tokens de ID de OIDC levan unha declaración de audiencia que nomea o cliente para o que se emitiron, e as asercións portadoras de SAML restrinxen a audiencia ao provedor de servizo receptor. Un segundo servizo que acepta a resposta do primeiro está mal configurado, e copiar un token a outra aplicación non é integración.

Rexiste cada aplicación interna e despois configure o contexto do navegador

Cada servizo necesita os valores SAML ou OIDC admitidos: emisor, identificador de cliente, URL de retorno de chamada ou de consumidor de asercións, declaracións requiridas e asignación. A accesibilidade vén por riba, porque as comprobacións de identidade nunca fornecen unha ruta nin unha resposta DNS.

1. Cree a entrada da aplicación e confirme que o ID de entidade ou de cliente coincide co que envía a aplicación.
2. Rexiste a URL exacta de retorno de chamada, incluíndo esquema e porto; un erro leve falla despois de que o usuario se autentique.
3. Asigne os usuarios ou grupos e despois confirme que se emiten as declaracións requiridas.
4. Permita os puntos finais do provedor de identidade xunto coa aplicación privada, ou a redirección non poderá completarse.

O contexto do navegador decide se se reutiliza unha sesión existente do provedor. Un cliente nativo que abre o navegador do sistema pode compartir ese estado, mentres que unha vista integrada co seu propio tarro de cookies normalmente non pode. Un navegador novo, as ventás privadas e un segundo perfil comezan de cero, o cal é esperable e non unha configuración SSO rota.

Executa o fluxo e le onde se detén

Reproduza co panel de rede do navegador e observe a cadea de redireccións. Un percorrido útil segue un salto cada vez: da pasarela ao provedor, do provedor de volta á aplicación cun código ou unha aserción, da aplicación ao punto final de tokens do provedor, e a sesión da aplicación emitida. O salto onde se detén a cadea nomea o compoñente que hai que corrixir.

Dúas comprobacións de liña de ordes resolven as dúbidas habituais, e ambas son seguras de executar desde un host de administración:

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

Cando os metadatos enumeran puntos finais que nunca rexistrou, a aplicación apunta a outro inquilino ou emisor. Cando a primeira solicitude á aplicación responde 302 cara a un host inesperado, a configuración de federación da aplicación é o lugar onde mirar, non o perfil de VPN.

Corrixa os avisos descubrindo quen os pediu

Un segundo aviso de contrasinal non é automaticamente un defecto. A aplicación pode solicitar un nivel de garantía máis alto, ou ben o provedor pode impoñer unha idade máxima de sesión e un novo desafío. Eliminar eses requisitos para que o fluxo sexa máis silencioso debilita un control deliberado, así que estableza que compoñente o pediu antes de cambiar a política.

Logo decida que mellorar. Se o aviso vén da aplicación, corrixa a súa entrada de federación. Se vén do provedor por política, documente o requisito. Se non se pode acceder á aplicación tras un inicio de sesión correcto, o enrutamento do túnel é o sospeitoso, porque a identidade e a entrega de paquetes fallan en lugares distintos e parecen similares desde o asento do usuario.