AWS Client VPN SAML и Google Workspace: пропускът при обратното извикване

Страницата app_not_configured_for_user идва от Google Workspace и се появява преди да е договорен дори един пакет по тунела. Този ред е целият диагноз. Преинсталирането на клиента, редактирането на профила или проверката на маршрутите не могат да изчистят страница, която крайната точка на VPN още не е видяла. Стъпката, която се проваля, е предаване в браузъра между доставчика на идентичност и слушател на самата машина на потребителя, и в това предаване има точно три неща, които си струва да се проверят.

Четете страницата като изявление на доставчика на идентичност

Google връща това, когато SAML приложението не е включено за акаунта, който се е вписал. Приложението може да е изключено, потребителят може да е извън зададената организационна единица или група, или настройките на доставчика на услуги може да не съвпадат с това, което заявката е поискала.

Нищо от това не е проблем със сертификат, маршрут или тунел, макар че потребителят го е забелязал в VPN клиента.

Двете стойности, които клиентът ще приеме

AWS Client VPN извършва SAML обмен, иницииран от доставчика на услуги, така че клиентът отваря браузър, потребителят се удостоверява, а доставчикът изпраща подписано твърдение обратно към адрес на Assertion Consumer Service. За настолния клиент, предоставен от AWS този адрес е слушател на loopback, обикновено порт 35001, а очакваната аудитория е идентификаторът на обекта на SAML приложението за Client VPN, а не обектът за вход в конзолата на AWS.

И двете стойности трябва да съвпадат с това, което клиентът очаква: къде се изпраща твърдението и към кого е адресирано. Конфигурация, копирана от SSO приложение в конзолата, може да изглежда напълно правдоподобна и пак да е насочена към грешната двойка.

Вземайте двете стойности от изискванията за Client VPN SAML, а не от общо ръководство за единен вход в AWS. SSO обектът в конзолата изглежда достатъчно подобен, за да е изкушаващ. Това е различно приложение с различна аудитория и клиентът отхвърля твърдението, без да се обяснява. Копирайте двойката веднъж и я съхранете до профила.

Google няма да приеме обратното извикване по обикновен HTTP

Административната конзола изисква HTTPS адрес за ACS, а обратното извикване на клиента е обикновен HTTP на loopback. Тази стойност изобщо не може да се въведе в конфигурацията на приложението в Workspace, затова някои екипи опитват обратен прокси, който терминира TLS и препраща към локалния слушател. Това не поправя несъответствието: браузърът вижда един origin, клиентът обявява друг, а върнатият отговор може да пристигне с грешна дестинация.

Работещото решение е посреднически доставчик на идентичност. SAML приложението при посредника получава обратното извикване на loopback и аудиторията на AWS, а посредникът федерира акаунта в Workspace нагоре. Правилото за HTTPS на Google остава изпълнено и твърдението, което стига до клиента, все още назовава адреса и аудиторията, които той очаква.

Този посредник е административна зависимост, която някой трябва да притежава, наблюдава и включва при прекратяване на достъпа. Това е и второ място, където прекъсване се превръща в неуспешен вход. Оценете цената му, преди да обещаете дизайна. Ако никой няма да го притежава, честният отговор е, че клиентът на AWS не може да използва Workspace като единствен доставчик на идентичност.

Възлагане и двустепенно потвърждение

Преди да преработвате каквото и да е, потвърдете, че приложението е включено за правилната организационна единица или група и че приложенията на трети страни за SAML имат собствени контроли за възлагане, отделни от списъка с приложения от страна на Google.

Проверете също дали за акаунта е включено двустепенно потвърждение. Google може да го изисква, преди SAML приложение да стане използваемо за потребител, и един отговор в първоначалната тема беше решен точно така. Това е най-евтиното за изключване и най-досадното за откриване последно.

Проверете с чиста сесия

След всяка промяна тествайте с нов профил на браузъра и чиста конфигурация на клиента. Кешираните твърдения и преизползваните сесии скриват дали поправката е сработила.

След това сравнете два записа един до друг: събитието за одит на доставчика на идентичност и журнала на клиента. Успешен вход без тунел сочи обратно към обратното извикване или аудиторията. Свързан тунел с недостъпен ресурс е проблем с маршрутизация или оторизация и принадлежи съвсем другаде.

Какво да не променяте

Не премахвайте auth-federate от профила и не изключвайте проверките на сертификати, за да подминете страницата. И двете променят дизайна на удостоверяване, а не повреденото обратно извикване, и двете обикновено се чупят при следващото обновяване на клиента.

Поправете вместо това предаването и оставете бележка, която назовава посредника, аудиторията и порта на loopback. Следващият човек, който види страницата, ще се нуждае и от трите.