AWS Client VPN SAML ו-Google Workspace: פער ה-callback

הדף app_not_configured_for_user מגיע מ-Google Workspace ומופיע לפני שמנותחת ולו חבילת מנהרה אחת. הסדר הזה הוא כל האבחון. התקנה מחדש של הלקוח, עריכת הפרופיל או בדיקת המסלולים לא יכולות לנקות דף שנקודת הקצה של ה-VPN עוד לא ראתה. השלב שנכשל הוא מסירה בדפדפן בין ספק הזהות למאזין במחשב של המשתמש עצמו, ובמסירה הזו יש בדיוק שלושה דברים ששווה לבדוק.

קראו את הדף כהצהרה של ספק הזהות

Google מחזיר את זה כאשר אפליקציית ה-SAML אינה מופעלת עבור החשבון שהתחבר. ייתכן שהאפליקציה כבויה, שהמשתמש נמצא מחוץ ליחידה הארגונית או לקבוצה שהוקצו, או שהגדרות ספק השירות אינן תואמות למה שהבקשה דרשה.

שום דבר מזה אינו בעיית תעודה, מסלול או מנהרה, למרות שהמשתמש הבחין בזה בלקוח ה-VPN.

שני הערכים שהלקוח יקבל

AWS Client VPN מבצע חילופי SAML ביוזמת ספק השירות, כך שהלקוח פותח דפדפן, המשתמש מאמת את עצמו, והספק שולח הצהרה חתומה חזרה לכתובת Assertion Consumer Service. עבור לקוח שולחן העבודה שמספקת AWS הכתובת הזו היא מאזין על loopback, בדרך כלל פורט 35001, והקהל הצפוי הוא מזהה הישות של אפליקציית ה-SAML של Client VPN, ולא ישות הכניסה של קונסולת AWS.

שני הערכים חייבים להתאים למה שהלקוח מצפה לו: היכן מופרסמת ההצהרה ולמי היא ממוענת. תצורה שהועתקה מאפליקציית SSO בקונסולה יכולה להיראות סבירה לחלוטין ובכל זאת לפנות לזוג הלא נכון.

קחו את שני הערכים מדרישות ה-SAML של Client VPN, ולא ממדריך כללי לכניסה אחודה ב-AWS. ישות ה-SSO בקונסולה נראית דומה מספיק כדי לפתות. זו אפליקציה אחרת עם קהל אחר, והלקוח דוחה את ההצהרה בלי להסביר את עצמו. העתיקו את הזוג פעם אחת ושמרו אותו לצד הפרופיל.

Google לא יקבל את ה-callback ב-HTTP פשוט

קונסולת הניהול דורשת כתובת 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. האדם הבא שיראה את הדף יצטרך את כל השלושה.