Какво се случва в браузърната стъпка при федеративен вход във VPN

Натискате Connect и вместо поле за парола VPN клиентът отваря браузъра ви. Това предаване обърква хора, които очакват тунелът да се автентикира сам. Браузърът не е обходен път: именно там доставчикът на идентичност реално автентикира човека, а клиентът само чака резултата.

Проследяването на един вход от начало до край показва къде принадлежи всяка повреда — а точно тази част повечето runbook-ове пропускат.

Започнете от клиента, не от конфигурацията на шлюза

Клиентът изгражда заявка и изпраща браузъра до доставчика на идентичност с идентификатор на доставчика на услуги и адрес за връщане. След това IdP на организацията ви изпълнява каквото е конфигуриран: парола, MFA, проверка на устройство, условен достъп. Ако браузърът вече има валидна сесия, видимата част може да отнеме секунда-две. Тази краткост е повторно използване на сесия, а не пропусната проверка.

Прочетете във федеративната конфигурация на клиента две стойности преди всичко друго: метаданните или URL на IdP, на който се доверява, и адреса за обратно извикване, който очаква. Несъответствие там води до провал още преди да е въведена парола.

Какво трябва да върне доставчикът на идентичност

IdP отговаря с подписан SAML отговор, съдържащ assertion: кой е субектът, кой го е издал, за кого е и колко дълго е валиден. Тези полета са договорът. Издател, аудитория, получател и прозорец на валидност трябва да съвпадат с очакваното от услугата.

Отговор, подписан от правилния IdP, но адресиран до друга аудитория, пак е невалиден. Именно тази проверка се пропуска, когато метаданни се копират от лаборатория в продукция.

Какво проверява VPN услугата, преди да ви се довери

Услугата проверява подписа срещу доверения сертификат, проверява издателя, аудиторията и получателя, после оценява времевите условия. Едва след това свързва assertion с потребител или група и прилага политиката за оторизация на VPN. Тук автентикацията и оторизацията са отделни стъпки и валиден assertion без съответстваща група дава сесия, която се свързва и не достига до нищо.

Assertion е материал за автентикация, не парола. Поставянето му в друг клиент или запазването му за по-късно повторно свързване не е поддържан вход.

Два живота, които свършват поотделно

Сесията в браузъра при IdP и VPN сесията при шлюза изтичат по различен часовник. Излизането от IdP не разкъсва непременно установен тунел, а прекъсването на тунела не ви извежда от браузъра.

AWS Client VPN документира, че федеративният му поток не поддържа единично излизане по SAML, което е конкретен пример за тази разлика. Проверявайте своята услуга, вместо да предполагате симетрия.

Затова повторното свързване се държи различно в 09:00 и в 15:00. То може тихо да използва отново IdP сесията, да поиска MFA отново или да се провали, защото продължителността на сесията на крайната точка е изтекла, а тази в браузъра — не. Работният поток за федерация на AWS описва своите изисквания към клиента и отговора, а други услуги използват различни предавания.

Когато браузърната стъпка се провали, проверете тези по ред

Работете от браузъра навън, защото съобщението за грешка обикновено назовава последния, а не първия етап.

Ако страницата не се зареди, URL на IdP в клиента или пътят до него е грешен. Ако IdP отхвърли заявката, идентификаторът на доставчика на услуги или адресът за връщане не съвпадат с конфигурацията му. Ако браузърът покаже успех, а клиентът пак се провали, отговорът е стигнал на грешно място или е пропаднал проверката за аудитория и време. А ако тунелът се вдигне без достъп, assertion е приет, но свързването с група не е.

Дръжте очакваната страница, адреса за връщане и свързването с група в един документ. Тогава потребител, който съобщи за счупен VPN вход, може да каже кое от тези четири неща е видял, и отговорът вече е наполовина написан.