ახდენს 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 პროფილი.

გაასწორეთ მოთხოვნები იმის გარკვევით, ვინ ითხოვა

მეორე პაროლის მოთხოვნა ავტომატურად ნაკლი არ არის. აპმა შეიძლება უფრო მაღალი დაცვის დონე მოითხოვოს, ან მომწოდებელმა შეიძლება სესიის მაქსიმალური ასაკი და ახალი გამოწვევა დააწესოს. ამ მოთხოვნების მოშორება ნაკადის გასაწყნარებლად ასუსტებს განზრახ კონტროლს, ამიტომ პოლიტიკის შეცვლამდე დაადგინეთ, რომელმა კომპონენტმა მოითხოვა.

შემდეგ გადაწყვიტეთ, რა გააუმჯობესოთ. თუ მოთხოვნა აპიდან მოდის, გაასწორეთ მისი ფედერაციის ჩანაწერი. თუ პოლიტიკის მიხედვით მომწოდებლიდან მოდის, დააფიქსირეთ მოთხოვნა. თუ აპი წარმატებული შესვლის შემდეგ მიუწვდომელია, საეჭვოა გვირაბის მარშრუტიზაცია, რადგან იდენტობა და პაკეტების მიწოდება სხვადასხვა ადგილას ვარდება და მომხმარებლის ადგილიდან ერთნაირად გამოიყურება.