VPN SSO ลงชื่อเข้าใช้แอปภายในให้ผู้ใช้อัตโนมัติหรือไม่?

เกตเวย์ VPN ที่ตรวจสอบสิทธิ์ผ่านผู้ให้บริการระบุตัวตนพิสูจน์เพียงสิ่งเดียว: ผู้ให้บริการรับรองผู้ใช้ต่อหน้าเกตเวย์ มันไม่ได้มอบข้อมูลรับรองให้ผู้ใช้รายนั้นสำหรับวิกิของเครือข่ายภายใน แดชบอร์ดตรวจสอบ หรือเซิร์ฟเวอร์บิลด์ บริการเหล่านั้นลงชื่อเข้าใช้ผู้คนผ่านสหพันธ์ของตนเองและใช้การอนุญาตของตนเอง และอุโมงค์เพียงตัดสินว่าแพ็กเก็ตใดเข้าถึงบริการเหล่านั้นได้

สามเซสชัน สามการตัดสินใจแยกกัน

แยกสถานะออกจากกัน เพราะแต่ละอย่างหมดอายุตามกำหนดของตัวเอง เซสชัน VPN คือการที่เกตเวย์ยอมรับตัวตนบวกกับการเข้าถึงเครือข่ายที่มอบให้ เซสชันเบราว์เซอร์ที่ผู้ให้บริการระบุตัวตนคือสิ่งที่เบราว์เซอร์ยังคงเก็บไว้สำหรับผู้ให้บริการรายนั้นและอาจนำกลับมาใช้ซ้ำตามนโยบาย เซสชันแอปพลิเคชันเป็นของบริการหนึ่งที่ตรวจสอบการตอบกลับที่ส่งถึงตนแล้ว

การสับสนสถานะเหล่านี้ทำให้เกิดคำถามผิด มักอยู่ในรูปทำไมอุโมงค์จึงไม่ลงชื่อเข้าใช้ผู้ใช้ทุกที่ ลองเขียนใหม่: แอปใดไม่มีรายการสหพันธ์ แอปใดปฏิเสธผู้ใช้ และแอปใดขาดเส้นทาง คำขอลงชื่อเข้าใช้ครั้งเดียวที่เปิดแอปเครือข่ายภายในยังอาจเด้งกลับไปหาผู้ให้บริการได้ เพราะการเปลี่ยนเส้นทางครั้งที่สองคือคำขออนุญาตใหม่สำหรับผู้ชมอื่น

เชื่อมต่อเกตเวย์ในฐานะแอปของตนเอง

ลงทะเบียน VPN เป็นแอปที่ได้รับอนุมัติในผู้ให้บริการ พร้อมตัวระบุ URI การเปลี่ยนเส้นทาง และการกำหนดผู้ใช้ของตนเอง จากนั้นตัดสินใจว่าการลงชื่อเข้าใช้ครั้งนั้นให้สิทธิ์เครือข่ายใด เพราะนั่นคือนโยบาย VPN ไม่ใช่คุณสมบัติของผู้ให้บริการ ผู้ใช้ที่ควรเข้าถึงเฉพาะซับเน็ตตรวจสอบจะได้รับนโยบายเกตเวย์อื่น ไม่ใช่รหัสผ่านอื่น

การตอบกลับการตรวจสอบสิทธิ์ของอุโมงค์ไม่ใช่ข้อมูลรับรองที่ใช้ซ้ำได้ โทเค็น ID ของ OIDC มีข้ออ้างผู้ชมที่ระบุไคลเอนต์ที่ออกให้ และการยืนยันแบบผู้ถือของ 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

แก้ไขคำขอโดยค้นหาว่าใครเป็นผู้ขอ

การขอรหัสผ่านครั้งที่สองไม่ได้เป็นข้อบกพร่องโดยอัตโนมัติ แอปอาจขอระดับความเชื่อมั่นที่สูงขึ้น หรือ ผู้ให้บริการอาจบังคับอายุเซสชันสูงสุดและการท้าทายใหม่. การลบข้อกำหนดเหล่านั้นเพื่อให้โฟลว์เงียบขึ้นจะทำให้การควบคุมที่ตั้งใจไว้อ่อนแอลง ดังนั้นจงระบุว่าองค์ประกอบใดเป็นผู้ขอก่อนเปลี่ยนนโยบาย

จากนั้นตัดสินใจว่าจะปรับปรุงอะไร หากคำขอมาจากแอป ให้แก้ไขรายการสหพันธ์ของแอปนั้น หากมาจากผู้ให้บริการตามนโยบาย ให้บันทึกข้อกำหนดไว้ หากแอปเข้าถึงไม่ได้หลังลงชื่อเข้าใช้สำเร็จ การกำหนดเส้นทางของอุโมงค์คือผู้ต้องสงสัย เพราะ ตัวตนและการส่งมอบแพ็กเก็ตล้มเหลวในตำแหน่งที่ต่างกัน และดูคล้ายกันจากที่นั่งของผู้ใช้