Да ли 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 профил.

Поправите захтеве тако што ћете открити ко их је затражио

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

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