Дали VPN SSO автоматски ги најавува корисниците во внатрешните апликации?

VPN портата што се автентицира преку давател на идентитет докажува едно нешто: давателот гарантирал за корисникот пред портата. Таа не му дава на тој корисник акредитив за внатрешниот вики, контролната табла за следење или серверот за изградба. Тие услуги ги најавуваат луѓето преку сопствената федерација и применуваат сопствена авторизација, а тунелот само одлучува кои пакети можат да стигнат до нив.

Три сесии, три одделни одлуки

Држете ги состојбите одделно, бидејќи секоја истекува по сопствен распоред. VPN сесијата е прифаќање на идентитет од портата плус мрежниот пристап што го дала. Сесијата на прелистувачот кај давателот на идентитет е она што прелистувачот сѐ уште го чува за тој давател и може повторно да го користи според неговата политика. Сесијата на апликацијата припаѓа на една услуга што валидирала одговор упатен до неа.

Мешањето на тие состојби го дава погрешното прашање, обично формулирано како зошто тунелот не го најавува корисникот насекаде. Преформулирајте: која апликација нема запис за федерација, која го одбива корисникот и на која ѝ недостига рута. Едно барање за најава што ја отвора внатрешната апликација сѐ уште може да се врати кај давателот, бидејќи второто пренасочување е ново барање за авторизација за друга публика.

Поврзете ја портата како сопствена апликација

Регистрирајте го VPN како одобрена апликација кај давателот, со сопствен идентификатор, URI за пренасочување и доделување корисници. Потоа одлучете кои мрежни авторизации ги дава таа најава, бидејќи тоа е VPN политика, а не функција на давателот. Корисниците што треба да стигнат само до подсетот за следење добиваат друга политика на портата, а не друга лозинка.

Одговорот за автентикација на тунелот не е акредитив што може повторно да се користи. OIDC ID токените носат тврдење за публиката што го именува клиентот за кој се издадени, а SAML bearer тврдењата ја ограничуваат публиката на услугата што ги прима. Втора услуга што го прифаќа одговорот на првата е погрешно конфигурирана, а копирањето токен во друга апликација не е интеграција.

Регистрирајте ја секоја внатрешна апликација, потоа поставете го контекстот на прелистувачот

Секоја услуга ги бара поддржаните SAML или OIDC вредности: издавач, идентификатор на клиент, URL за повратен повик или за потрошувач на тврдење, потребни тврдења и доделување. Достапноста доаѓа одозгора, бидејќи проверките на идентитет никогаш не даваат рута или одговор од DNS.

1. Создајте го записот за апликацијата и потврдете дека ID на ентитет или клиент се совпаѓа со она што го праќа апликацијата.
2. Регистрирајте го точниот URL за повратен повик, вклучително шема и порта; мала грешка пропаѓа откако корисникот ќе се автентицира.
3. Доделете ги корисниците или групите, потоа потврдете дека потребните тврдења се издаваат.
4. Дозволете ги крајните точки на давателот на идентитет и приватната апликација, инаку пренасочувањето не може да заврши.

Контекстот на прелистувачот одлучува дали постоечката сесија на давателот ќе се користи повторно. Роден клиент што го отвора системскиот прелистувач може да ја сподели таа состојба, додека вградениот приказ со сопствена тегла за колачиња обично не може. Нов прелистувач, приватни прозорци и втор профил почнуваат од нула, што е очекувано, а не расипана SSO конфигурација.

Стартувајте го текот и прочитајте каде запира

Репродуцирајте со мрежниот панел на прелистувачот и набљудувајте го синџирот на пренасочувања. Корисно поминување следи еден скок одеднаш: од портата кон давателот, од давателот назад кон апликацијата со код или тврдење, од апликацијата кон крајната точка за токени на давателот, издадена сесија на апликацијата. Скокот каде синџирот запира го именува компонентот што треба да се поправи.

Две проверки од командната линија ги решаваат вообичаените сомнежи и двете се безбедни за извршување од администраторски домаќин:

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

Кога метаподатоците наведуваат крајни точки што никогаш не сте ги регистрирале, апликацијата покажува кон друг закупец или издавач. Кога првото барање до апликацијата одговара 302 кон неочекуван домаќин, конфигурацијата за федерација на апликацијата е местото за проверка, а не профилот за VPN.

Поправете ги барањата така што ќе откриете кој ги побарал

Второ барање за лозинка не е автоматски дефект. Апликацијата може да бара повисоко ниво на гаранција, или давателот може да наметне максимална возраст на сесијата и нов предизвик. Отстранувањето на тие барања за да биде текот потивок ја ослабува намерната контрола, затоа утврдете кој компонент ги побарал пред да ја смените политиката.

Потоа одлучете што да се подобри. Ако барањето доаѓа од апликацијата, поправете го нејзиниот запис за федерација. Ако доаѓа од давателот според политика, документирајте го барањето. Ако апликацијата е недостапна по успешна најава, сомнително е рутирањето на тунелот, бидејќи идентитетот и доставата на пакети пропаѓаат на различни места и изгледаат слично од местото на корисникот.