Արդյո՞ք VPN SSO-ն օգտատերերին ավտոմատ կերպով մուտք է գործում ներքին հավելվածներ։

Մեկ մուտքը կարող է ծածկել թունելը և դրա հետևի հավելվածները, բայց միայն այն դեպքում, երբ յուրաքանչյուր հավելված ունի իր վստահությունը: Ահա հաջորդականությունը՝ այն միացնելու և ստուգելու համար:

Ինքնության մատակարարի միջոցով նույնականացում կատարող VPN դարպասը ապացուցում է մեկ բան. մատակարարը երաշխավորել է օգտատիրոջը դարպասի առաջ: Այն այդ օգտատիրոջը չի տալիս հավատարմագիր ներքին ցանցի վիքիի, մոնիտորինգի վահանակի կամ build-սերվերի համար: Այդ ծառայությունները մարդկանց մուտք են գործում իրենց ֆեդերացիայի միջոցով և կիրառում են իրենց լիազորումը, իսկ թունելը միայն որոշում է, թե որ փաթեթները կարող են հասնել նրանց:

Երեք սեսիա, երեք առանձին որոշում

Պահեք վիճակները առանձին, քանի որ յուրաքանչյուրը լրանում է իր ժամանակացույցով: VPN սեսիան դարպասի կողմից ինքնության ընդունումն է գումարած տրված ցանցային հասանելիությունը: Ինքնության մատակարարի մոտ բրաուզերի սեսիան այն է, ինչ բրաուզերը դեռ պահում է այդ մատակարարի համար և կարող է կրկին օգտագործել իր քաղաքականության համաձայն: Հավելվածի սեսիան պատկանում է մեկ ծառայության, որը վավերացրել է իրեն ուղղված պատասխան:

Այս վիճակների շփոթումը ստեղծում է սխալ հարց, սովորաբար ձևակերպված որպես ինչու թունելը օգտատիրոջը ամենուր չի մուտք գործում: Վերաձևակերպեք՝ ո՞ր հավելվածը ֆեդերացիայի գրառում չունի, որը մերժում է օգտատիրոջը, և որին բացակայում է երթուղի: Մեկ մուտքի հուշում, որը բացում է ներքին ցանցի հավելվածը, այնուամենայնիվ կարող է վերադառնալ մատակարարին, քանի որ երկրորդ վերահասցեավորումը նոր լիազորման հարցում է այլ լսարանի համար:

Միացրեք դարպասը որպես իր սեփական հավելված

Գրանցեք VPN-ը մատակարարի մոտ որպես հաստատված հավելված՝ իր սեփական նույնացուցիչով, վերահասցեավորման URI-ով և օգտատերերի նշանակմամբ: Այնուհետև որոշեք, թե այդ մուտքը ինչ ցանցային լիազորումներ է տալիս, քանի որ դա VPN քաղաքականություն է, ոչ թե մատակարարի գործառույթ: Օգտատերերը, ովքեր պետք է հասնեն միայն մոնիտորինգի ենթացանցին, ստանում են այլ դարպասային քաղաքականություն, ոչ թե այլ գաղտնաբառ:

Թունելի նույնականացման պատասխանը վերօգտագործելի հավատարմագիր չէ: OIDC ID նշանները կրում են լսարանի պնդում, որը նշում է այն հաճախորդին, ում համար դրանք թողարկվել են, իսկ SAML կրող հայտարարությունները լսարանը սահմանափակում են ընդունող ծառայության մատակարարով: Երկրորդ ծառայությունը, որն ընդունում է առաջինի պատասխանը, սխալ է կարգավորված, և նշանը այլ հավելված պատճենելը ինտեգրում չէ:

Գրանցեք յուրաքանչյուր ներքին հավելված, ապա կարգավորեք բրաուզերի համատեքստը

Յուրաքանչյուր ծառայության անհրաժեշտ են աջակցվող 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 պրոֆիլը:

Ուղղեք հուշումները՝ գտնելով, թե ով է խնդրել

Երկրորդ գաղտնաբառի հուշումը ինքնաբերաբար թերություն չէ: Հավելվածը կարող է պահանջել ավելի բարձր երաշխիքի մակարդակ, կամ մատակարարը կարող է պարտադրել սեսիայի առավելագույն տարիք և նոր մարտահրավեր. Այդ պահանջները հեռացնելը՝ հոսքը ավելի հանգիստ դարձնելու համար, թուլացնում է դիտավորյալ վերահսկողությունը, ուստի նախ որոշեք, թե որ բաղադրիչն է պահանջել, հետո փոխեք քաղաքականությունը:

Ապա որոշեք, թե ինչ բարելավել: Եթե հուշումը գալիս է հավելվածից, ուղղեք դրա ֆեդերացիայի գրառումը: Եթե այն գալիս է մատակարարից՝ ըստ քաղաքականության, փաստաթղթավորեք պահանջը: Եթե հավելվածն անհասանելի է հաջող մուտքից հետո, կասկածելի է թունելի երթուղայնությունը, քանի որ ինքնությունը և փաթեթների առաքումը ձախողվում են տարբեր տեղերում և օգտատիրոջ տեղից նույն տեսքն ունեն:

Առնչվող հոդվածներ