AWS Client VPN SAML กับ Google Workspace: ช่องว่างของ callback

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

อ่านหน้าเว็บนั้นเป็นถ้อยแถลงของผู้ให้บริการระบุตัวตน

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

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

สองค่าที่ไคลเอนต์จะยอมรับ

AWS Client VPN ทำการแลกเปลี่ยน SAML ที่ผู้ให้บริการเป็นผู้เริ่ม ดังนั้นไคลเอนต์จะเปิดเบราว์เซอร์ ผู้ใช้พิสูจน์ตัวตน และผู้ให้บริการส่งข้อความยืนยันที่ลงนามแล้วกลับไปยัง URL ของ Assertion Consumer Service สำหรับ ไคลเอนต์เดสก์ท็อปที่ AWS จัดให้ URL นั้นคือตัวรับฟังบน loopback โดยปกติคือพอร์ต 35001 และผู้รับที่คาดหวังคือตัวระบุเอนทิตีของแอปพลิเคชัน SAML ของ Client VPN ไม่ใช่เอนทิตีการลงชื่อเข้าใช้ของคอนโซล AWS

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

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

Google จะไม่ยอมรับ callback แบบ HTTP ธรรมดา

คอนโซลผู้ดูแลระบบกำหนดให้ใช้ URL ของ ACS แบบ HTTPS แต่ callback ของไคลเอนต์เป็น HTTP ธรรมดาบน loopback ค่านั้นพิมพ์ลงในการกำหนดค่าแอป Workspace ไม่ได้เลย นี่คือเหตุผลที่บางทีมลองพร็อกซีย้อนกลับที่ยุติ TLS แล้วส่งต่อไปยังตัวรับฟังภายในเครื่อง นั่นไม่ได้แก้ความไม่ตรงกัน เพราะเบราว์เซอร์เห็นต้นกำเนิดหนึ่ง ไคลเอนต์ประกาศอีกต้นกำเนิดหนึ่ง และการตอบกลับที่ส่งคืนอาจไปถึงปลายทางผิด

รูปแบบที่ได้ผลคือผู้ให้บริการระบุตัวตนแบบตัวกลาง แอปพลิเคชัน SAML ที่ตัวกลางได้รับ callback แบบ loopback และผู้รับของ AWS และตัวกลางจะรวมบัญชี Workspace ไว้ต้นทาง กฎ HTTPS ของ Google ยังคงได้รับการตอบสนอง และข้อความยืนยันที่ไปถึงไคลเอนต์ยังระบุที่อยู่และผู้รับที่คาดหวัง

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

การกำหนดและการยืนยันสองขั้นตอน

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

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

ตรวจสอบด้วยเซสชันที่สะอาด

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

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

สิ่งที่ไม่ควรเปลี่ยน

อย่าถอด auth-federate ออกจากโปรไฟล์หรือปิดการตรวจสอบใบรับรองเพื่อผ่านหน้านั้น ทั้งสองอย่างเปลี่ยนการออกแบบการพิสูจน์ตัวตนแทนที่จะแก้ callback ที่ล้มเหลว และทั้งสองอย่างมักพังในการอัปเดตไคลเอนต์ครั้งถัดไป

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