AWS Client VPN SAML ja Google Workspace: takaisinkutsun aukko
Google näyttää app_not_configured_for_user -sivun ennen kuin yhtään tunnelia on olemassa. Asiakasohjelma haluaa tavallisen HTTP-takaisinkutsun loopbackiin, jota Workspace ei hyväksy.
Sivu app_not_configured_for_user tulee Google Workspacesta ja ilmestyy ennen kuin yksikään tunnelipaketti on neuvoteltu. Tämä järjestys on koko diagnoosi. Asiakasohjelman uudelleenasennus, profiilin muokkaus tai reittien tarkistus ei voi poistaa sivua, jota VPN:n päätepiste ei ole vielä nähnyt. Epäonnistuva vaihe on selaimen kättely identiteetintarjoajan ja käyttäjän oman koneen kuuntelijan välillä, ja siinä kättelyssä kannattaa tarkistaa täsmälleen kolme asiaa.
Lue sivu identiteetintarjoajan lausuntona
Google palauttaa tämän, kun SAML-sovellus ei ole käytössä sillä tilillä, jolla kirjauduttiin. Sovellus voi olla pois päältä, käyttäjä voi olla määritetyn organisaatioyksikön tai ryhmän ulkopuolella, tai palveluntarjoajan asetukset eivät ehkä vastaa sitä, mitä pyyntö vaati.
Mikään tästä ei ole sertifikaatti-, reitti- tai tunneliongelma, vaikka käyttäjä huomasi sen VPN-asiakasohjelmassa.
Kaksi arvoa, jotka asiakasohjelma hyväksyy
AWS Client VPN käyttää palveluntarjoajan aloittamaa SAML-vaihtoa, joten asiakasohjelma avaa selaimen, käyttäjä todentaa itsensä ja tarjoaja lähettää allekirjoitetun väitteen takaisin Assertion Consumer Service -URL-osoitteeseen. AWS:n tarjoaman työpöytäasiakasohjelman osalta tämä URL on kuuntelija loopbackissa, yleensä portti 35001, ja odotettu yleisö on Client VPN SAML -sovelluksen entiteettitunniste, ei AWS-konsolin kirjautumisentiteetti.
Molempien arvojen on vastattava sitä, mitä asiakasohjelma odottaa: mihin väite lähetetään ja kenelle se on osoitettu. Konsolin SSO-sovelluksesta kopioitu kokoonpano voi näyttää täysin uskottavalta ja silti kohdistua väärään pariin.
Ota molemmat arvot Client VPN SAML -vaatimuksista, älä yleisestä AWS:n kertakirjautumisoppaasta. Konsolin SSO-entiteetti näyttää tarpeeksi samanlaiselta houkutellakseen. Se on eri sovellus, jolla on eri yleisö, ja asiakasohjelma hylkää väitteen selittämättä itseään. Kopioi pari kerran ja tallenna se profiilin viereen.
Google ei hyväksy tavallista HTTP-takaisinkutsua
Ylläpitokonsoli vaatii HTTPS-muotoisen ACS-URL:n, ja asiakasohjelman takaisinkutsu on tavallista HTTP:tä loopbackissa. Sitä arvoa ei voi lainkaan kirjoittaa Workspace-sovelluksen kokoonpanoon, minkä vuoksi jotkin tiimit kokeilevat käänteistä välityspalvelinta, joka päättää TLS:n ja välittää paikalliselle kuuntelijalle. Se ei korjaa ristiriitaa: selain näkee yhden originin, asiakasohjelma ilmoittaa toisen, ja palautuva vastaus voi saapua väärään kohteeseen.
Toimiva järjestely on välittävä identiteetintarjoaja. Välittäjän SAML-sovellus saa loopback-takaisinkutsun ja AWS:n yleisön, ja välittäjä federöi Workspace-tilin ylöspäin. Googlen HTTPS-sääntö pysyy täytettynä, ja asiakasohjelmalle saapuva väite nimeää edelleen odotetun osoitteen ja yleisön.
Tuo välittäjä on hallinnollinen riippuvuus, joka jonkun on omistettava, valvottava ja sisällytettävä käytöstä poistoon. Se on myös toinen paikka, jossa katko muuttuu kirjautumisvirheeksi. Hinnoittele se ennen kuin lupaat suunnitelman. Jos kukaan ei omista sitä, rehellinen vastaus on, ettei AWS-asiakasohjelma voi käyttää Workspacea ainoana identiteetintarjoajanaan.
Määritys ja kaksivaiheinen vahvistus
Ennen kuin suunnittelet mitään uudelleen, varmista että sovellus on päällä oikealle organisaatioyksikölle tai ryhmälle ja että kolmannen osapuolen SAML-sovelluksilla on omat määritysohjaimet erillään Googlen puolen sovellusluettelosta.
Tarkista myös, onko tilillä kaksivaiheinen vahvistus käytössä. Google voi vaatia sitä ennen kuin SAML-sovellus tulee käyttäjälle käyttökelpoiseksi, ja yksi vastaus alkuperäisessä ketjussa ratkesi juuri niin. Se on halvin asia sulkea pois ja harmillisin löytää viimeisenä.
Vahvista puhtaalla istunnolla
Testaa jokaisen muutoksen jälkeen uudella selainprofiililla ja puhtaalla asiakasohjelmakokoonpanolla. Välimuistiin tallennetut väitteet ja uudelleenkäytetyt istunnot peittävät, tuliko korjaus perille.
Vertaa sitten kahta kirjausta rinnakkain: identiteetintarjoajan auditointitapahtuma ja asiakasohjelman loki. Onnistunut kirjautuminen ilman tunnelia viittaa takaisinkutsuun tai yleisöön. Yhdistetty tunneli, jonka resurssiin ei pääse, on reititys- tai valtuutusongelma ja kuuluu aivan muualle.
Mitä ei pidä muuttaa
Älä poista auth-federate-merkintää profiilista äläkä poista sertifikaattitarkistuksia käytöstä päästäksesi sivun ohi. Molemmat muuttavat todennuksen suunnittelua eivätkä epäonnistuvaa takaisinkutsua, ja molemmat hajoavat yleensä seuraavassa asiakasohjelmapäivityksessä.
Korjaa sen sijaan kättely ja jätä muistiinpano, joka nimeää välittäjän, yleisön ja loopback-portin. Seuraava sivun näkevä henkilö tarvitsee kaikki kolme.