Meld VPN-SSO gebruikers outomaties by interne programme aan?

'n VPN-gateway wat deur 'n identiteitsverskaffer verifieer, bewys een ding: die verskaffer het vir die gateway ingestaan vir 'n gebruiker. Dit gee nie daardie gebruiker 'n geloofsbrief vir die intranet-wiki, die moniteringspaneel of die boubediener nie. Daardie dienste meld mense aan deur hul eie federasie en pas hul eie magtiging toe, en die tonnel besluit net watter pakkette hulle kan bereik.

Drie sessies, drie afsonderlike besluite

Hou die toestande apart, want elkeen verval volgens sy eie skedule. Die VPN-sessie is die gateway se aanvaarding van 'n identiteit plus die netwerktoegang wat dit verleen het. Die identiteitsverskaffer se blaaisessie is wat die blaaier steeds vir daardie verskaffer hou en volgens sy beleid kan hergebruik. Die programessie behoort aan een diens wat 'n antwoord gevalideer het wat aan hom gerig is.

Om daardie toestande te verwar, lewer die verkeerde vraag op, gewoonlik geformuleer as waarom die tonnel die gebruiker nie oral aanmeld nie. Herformuleer dit: watter program het geen federasie-inskrywing nie, watter een weier die gebruiker, en watter een kort 'n roete. 'n Enkele aanmeldingsprompt wat die intranetprogram oopmaak, kan steeds na die verskaffer terugspring, want die tweede herleiding is 'n nuwe magtigingsversoek vir 'n ander gehoor.

Koppel die gateway as sy eie program

Registreer die VPN as 'n goedgekeurde program by die verskaffer, met sy eie identifiseerder, herleidings-URI en gebruikerstoewysing. Besluit dan watter netwerkmagtigings daardie aanmelding verleen, want dit is 'n VPN-beleid eerder as 'n verskafferfunksie. Gebruikers wat net die moniteringsubnet moet bereik, kry 'n ander gateway-beleid, nie 'n ander wagwoord nie.

Die tonnel se verifikasie-antwoord is nie 'n herbruikbare geloofsbrief nie. OIDC ID-tokens dra 'n gehoor-eis wat die kliënt noem waarvoor hulle geskep is, en SAML-draerbewerings beperk die gehoor tot die ontvangende diensverskaffer. 'n Tweede diens wat die eerste diens se antwoord aanvaar, is verkeerd gekonfigureer, en om 'n token na 'n ander program te kopieer, is nie integrasie nie.

Registreer elke interne program, stel dan die blaaierkonteks

Elke diens benodig die ondersteunde SAML- of OIDC-waardes: uitreiker, kliëntidentifiseerder, terugroep- of bewering-verbruiker-URL, vereiste eise en toewysing. Bereikbaarheid kom daarby, want identiteitskontroles verskaf nooit 'n roete of 'n DNS-antwoord nie.

1. Skep die programinskrywing en bevestig die entiteit- of kliënt-ID stem ooreen met wat die program stuur.
2. Registreer die presiese terugroep-URL insluitend skema en poort; 'n byna-treffer misluk nadat die gebruiker verifieer het.
3. Wys die gebruikers of groepe toe en bevestig dan dat die vereiste eise vrygestel word.
4. Laat die identiteitsverskaffer se eindpunte sowel as die private program toe, anders kan die herleiding nie voltooi nie.

Die blaaierkonteks bepaal of 'n bestaande verskaffersessie hergebruik word. 'n Inheemse kliënt wat die stelselblaaier oopmaak, kan daardie toestand deel, terwyl 'n ingebedde aansig met sy eie koekiepot dit gewoonlik nie kan nie. Nuwe blaaier, private vensters en 'n tweede profiel begin van niks, wat verwag word eerder as 'n stukkende SSO-konfigurasie.

Voer die vloei uit en lees waar dit stop

Reproduseer met die blaaier se netwerkpaneel en kyk na die herleidingsketting. 'n Nuttige deurloop volg een sprong op 'n slag: gateway na verskaffer, verskaffer terug na die program met 'n kode of bewering, program na die verskaffer se token-eindpunt, programessie uitgereik. Die sprong waar die ketting stop, noem die komponent wat reggemaak moet word.

Twee opdragreëlkontroles besleg die gewone twyfel, en albei is veilig om vanaf 'n admin-gasheer te laat loop:

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

Wanneer die metadata eindpunte lys wat jy nooit geregistreer het nie, wys die program na 'n ander huurder of uitreiker. Wanneer die eerste versoek aan die program 302 antwoord na 'n onverwagte gasheer, is die program se federasiekonfigurasie die plek om te kyk, nie die VPN-profiel nie.

Maak prompts reg deur te vind wie gevra het

'n Tweede wagwoordprompt is nie outomaties 'n fout nie. Die program kan 'n hoër versekeringsvlak versoek, of die verskaffer kan 'n maksimum sessie-ouderdom en 'n nuwe uitdaging afdwing. Om daardie vereistes te verwyder om die vloei stiller te maak, verswak 'n doelbewuste beheer, so stel eers vas watter komponent gevra het voordat jy beleid verander.

Besluit dan wat om te verbeter. As die prompt van die program kom, maak sy federasie-inskrywing reg. As dit volgens beleid van die verskaffer kom, dokumenteer die vereiste. As die program onbereikbaar is ná 'n suksesvolle aanmelding, is die tonnel se roetering die verdagte, want identiteit en pakketaflewering faal op verskillende plekke en lyk soortgelyk uit die gebruiker se stoel.