AWS Client VPN SAML и Google Workspace: јаз у повратном позиву

Страница app_not_configured_for_user долази из Google Workspace-а и појављује се пре него што је договорен иједан пакет тунела. Тај редослед је цела дијагноза. Поновна инсталација клијента, уређивање профила или провера рута не могу уклонити страницу коју завршна тачка VPN-а још није видела. Корак који пада је преношење у прегледачу између добављача идентитета и слушаоца на корисниковом сопственом рачунару, а у том преношењу вреди проверити тачно три ствари.

Читајте страницу као изјаву добављача идентитета

Google ово враћа када SAML апликација није омогућена за налог који се пријавио. Апликација може бити искључена, корисник може бити изван додељене организационе јединице или групе, или се подешавања добављача услуга можда не поклапају са оним што је захтев тражио.

Ништа од тога није проблем сертификата, руте или тунела, иако је корисник то приметио у VPN клијенту.

Две вредности које ће клијент прихватити

AWS Client VPN спроводи SAML размену коју покреће добављач услуга, па клијент отвара прегледач, корисник се аутентификује, а добављач шаље потписану тврдњу назад на URL Assertion Consumer Service. За AWS-ов стони клијент тај URL је слушалац на loopback-у, обично порт 35001, а очекивана публика је идентификатор ентитета SAML апликације Client VPN, а не ентитет пријаве у AWS конзолу.

Обе вредности морају одговарати ономе што клијент очекује: где се тврдња шаље и коме је упућена. Конфигурација копирана из SSO апликације у конзоли може изгледати потпуно уверљиво и ипак циљати погрешан пар.

Узмите обе вредности из захтева Client VPN SAML, а не из општег водича за јединствену пријаву у AWS-у. SSO ентитет у конзоли изгледа довољно слично да буде примамљив. То је друга апликација с другом публиком, а клијент одбија тврдњу без објашњења. Копирајте пар једном и сачувајте га уз профил.

Google неће прихватити обичан HTTP повратни позив

Администраторска конзола захтева HTTPS ACS URL, а клијентов повратни позив је обичан HTTP на loopback-у. Та вредност се уопште не може уписати у конфигурацију Workspace апликације, зато неки тимови покушавају обрнути прокси који завршава TLS и прослеђује локалном слушаоцу. То не поправља неусклађеност: прегледач види једно порекло, клијент оглашава друго, а враћени одговор може стићи на погрешну дестинацију.

Решење које делује је посреднички добављач идентитета. SAML апликација код посредника добија loopback повратни позив и AWS публику, а посредник федерара Workspace налог према горе. Google-ово HTTPS правило остаје задовољено, а тврдња која стиже до клијента и даље наводи адресу и публику коју очекује.

Тај посредник је административна зависност коју неко мора поседовати, надзирати и укључити у одјаву. То је и друго место где се испад претвара у неуспелу пријаву. Израчунајте цену пре него што обећате дизајн. Ако га нико не буде поседовао, искрен одговор је да AWS клијент не може користити Workspace као свог јединог добављача идентитета.

Додела и двострука провера

Пре него што било шта редизајнирате, потврдите да је апликација укључена за исправну организациону јединицу или групу и да SAML апликације трећих страна имају сопствене контроле доделе одвојене од списка апликација на Google-овој страни.

Проверите и да ли је за налог омогућена двострука провера. Google је може захтевати пре него што SAML апликација постане употребљива кориснику, а један одговор у изворној расправи решен је управо тако. То је најјефтиније искључити и најнепријатније открити последње.

Проверите са чистом сесијом

Након сваке промене тестирајте са свежим профилом прегледача и чистом конфигурацијом клијента. Кеширане тврдње и поново коришћене сесије скривају да ли је поправка успела.

Затим упоредите два записа један уз други: ревизијски догађај добављача идентитета и дневник клијента. Успешна пријава без тунела упућује назад на повратни позив или публику. Повезан тунел са недоступним ресурсом је проблем усмеравања или ауторизације и припада сасвим другде.

Шта не мењати

Не уклањајте auth-federate из профила и не искључујте провере сертификата да бисте заобишли страницу. Обоје мења дизајн аутентификације, а не покварени повратни позив, и обоје се обично сломи при следећем ажурирању клијента.

Поправите уместо тога преношење и оставите белешку која наводи посредника, публику и loopback порт. Следећој особи која види страницу требаће све три.