Kirjaako VPN SSO käyttäjät automaattisesti sisäisiin sovelluksiin?

VPN-yhdyskäytävä, joka todentaa identiteetintarjoajan kautta, todistaa yhden asian: tarjoaja takasi käyttäjän yhdyskäytävälle. Se ei anna kyseiselle käyttäjälle tunnusta intranetin wikiin, valvontakojelautaan tai build-palvelimeen. Ne palvelut kirjaavat ihmisiä sisään oman federaationsa kautta ja soveltavat omaa valtuutustaan, ja tunneli päättää vain, mitkä paketit voivat päästä niihin.

Kolme istuntoa, kolme erillistä päätöstä

Pidä tilat erillään, koska jokainen vanhenee oman aikataulunsa mukaan. VPN-istunto on yhdyskäytävän hyväksyntä identiteetille sekä myönnetty verkkoyhteys. Identiteetintarjoajan selainistunto on se, mitä selain yhä säilyttää kyseiselle tarjoajalle ja voi käyttää uudelleen käytäntönsä mukaan. Sovellusistunto kuuluu yhdelle palvelulle, joka validoi sille osoitetun vastauksen.

Näiden tilojen sekoittaminen tuottaa väärän kysymyksen, joka yleensä muotoillaan kysymykseksi siitä, miksi tunneli ei kirjaa käyttäjää sisään kaikkialle. Muotoile se uudelleen: millä sovelluksella ei ole federaatiotietuetta, mikä hylkää käyttäjän ja miltä puuttuu reitti. Yksi kirjautumiskehote, joka avaa intranetin sovelluksen, voi silti palata tarjoajalle, koska toinen uudelleenohjaus on uusi valtuutuspyyntö eri yleisölle.

Kytke yhdyskäytävä omaksi sovelluksekseen

Rekisteröi VPN tarjoajassa hyväksytyksi sovellukseksi omalla tunnisteellaan, uudelleenohjaus-URI:llaan ja käyttäjäkohdistuksellaan. Päätä sitten, mitkä verkkovaltuudet kyseinen kirjautuminen myöntää, koska se on VPN-käytäntö eikä tarjoajan ominaisuus. Käyttäjät, joiden pitäisi päästä vain valvonta-aliverkkoon, saavat erilaisen yhdyskäytäväkäytännön, eivät erilaista salasanaa.

Tunnelin todennusvastaus ei ole uudelleenkäytettävä tunnus. OIDC ID -tunnukset kantavat yleisöväitteen, joka nimeää asiakasohjelman, jolle ne on myönnetty, ja SAML-kantajaesitykset rajaavat yleisön vastaanottavaan palveluntarjoajaan. Toinen palvelu, joka hyväksyy ensimmäisen vastauksen, on väärin konfiguroitu, eikä tunnuksen kopioiminen toiseen sovellukseen ole integraatiota.

Rekisteröi jokainen sisäinen sovellus ja aseta sitten selaimen konteksti

Jokainen palvelu tarvitsee tuetut SAML- tai OIDC-arvot: myöntäjä, asiakastunniste, takaisinkutsun tai väitteen kuluttajan URL, vaaditut väitteet ja kohdistus. Saavutettavuus tulee päälle, koska identiteettitarkistukset eivät koskaan tarjoa reittiä tai DNS-vastausta.

1. Luo sovellustietue ja varmista, että entiteetti- tai asiakastunnus vastaa sitä, mitä sovellus lähettää.
2. Rekisteröi tarkka takaisinkutsu-URL, mukaan lukien skeema ja portti; lähes oikea epäonnistuu, kun käyttäjä on todennettu.
3. Kohdista käyttäjät tai ryhmät ja varmista sitten, että vaaditut väitteet luovutetaan.
4. Salli identiteetintarjoajan päätepisteet sekä yksityinen sovellus, muuten uudelleenohjaus ei voi valmistua.

Selaimen konteksti päättää, käytetäänkö olemassa olevaa tarjoajan istuntoa uudelleen. Järjestelmäselaimen avaava natiiviasiakas voi jakaa tämän tilan, kun taas omalla evästepurillaan oleva upotettu näkymä ei yleensä voi. Uusi selain, yksityiset ikkunat ja toinen profiili alkavat tyhjästä, mikä on odotettua eikä rikkinäinen SSO-kokoonpano.

Aja kulku ja lue, mihin se pysähtyy

Toista selaimen verkkopaneelilla ja seuraa uudelleenohjausketjua. Hyödyllinen läpikäynti seuraa yhden hypyn kerrallaan: yhdyskäytävältä tarjoajalle, tarjoajalta takaisin sovellukseen koodin tai väitteen kanssa, sovelluksesta tarjoajan tunnuksen päätepisteeseen, sovellusistunto myönnetty. Hyppy, jossa ketju pysähtyy, nimeää korjattavan komponentin.

Kaksi komentorivitarkistusta ratkaisevat tavalliset epäilyt, ja molemmat on turvallista ajaa ylläpitäjän isännältä:

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

Kun metatiedot luettelevat päätepisteitä, joita et koskaan rekisteröinyt, sovellus osoittaa toiseen vuokralaiseen tai myöntäjään. Kun ensimmäinen pyyntö sovellukselle vastaa 302 odottamattomaan isäntään, sovelluksen federaatiokokoonpano on paikka, josta katsoa, ei VPN-profiili.

Korjaa kehotteet selvittämällä, kuka pyysi

Toinen salasanakehote ei ole automaattisesti vika. Sovellus voi pyytää korkeampaa varmuustasoa tai tarjoaja voi pakottaa istunnon enimmäisiän ja uuden haasteen. Näiden vaatimusten poistaminen kulun hiljentämiseksi heikentää tarkoituksellista valvontaa, joten selvitä, mikä komponentti pyysi, ennen kuin muutat käytäntöä.

Päätä sitten, mitä parantaa. Jos kehote tulee sovelluksesta, korjaa sen federaatiotietue. Jos se tulee tarjoajalta käytännön perusteella, dokumentoi vaatimus. Jos sovellus ei ole saavutettavissa onnistuneen kirjautumisen jälkeen, epäilty on tunnelin reititys, koska identiteetti ja pakettien toimitus epäonnistuvat eri kohdissa ja näyttävät samanlaisilta käyttäjän istuimelta.