האם SSO של VPN מחבר משתמשים אוטומטית לאפליקציות פנימיות?

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

שלושה מושבים, שלוש החלטות נפרדות

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

ערבוב של המצבים האלה מייצר את השאלה הלא נכונה, שבדרך כלל מנוסחת כשאלה מדוע המנהרה אינה מחברת את המשתמש בכל מקום. נסחו אותה מחדש: לאיזו אפליקציה אין רשומת פדרציה, איזו דוחה את המשתמש, ולאיזו חסר מסלול. בקשת התחברות אחת שפותחת את אפליקציית הרשת הפנימית עדיין יכולה לחזור לספק, מפני שההפניה השנייה היא בקשת הרשאה חדשה לקהל אחר.

חברו את השער כאפליקציה משל עצמו

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

תגובת האימות של המנהרה אינה אישור גישה לשימוש חוזר. אסימוני ID של OIDC נושאים הצהרת קהל שמציינת את הלקוח שעבורו הונפקו, והצהרות נושא של SAML מגבילות את הקהל לספק השירות המקבל. שירות שני שמקבל את תגובת השירות הראשון מוגדר באופן שגוי, והעתקת אסימון לאפליקציה אחרת אינה אינטגרציה.

רשמו כל אפליקציה פנימית, ואז הגדירו את הקשר הדפדפן

כל שירות זקוק לערכי SAML או OIDC הנתמכים: מנפיק, מזהה לקוח, כתובת URL לקריאה חוזרת או לצרכן הצהרות, הצהרות נדרשות והקצאה. נגישות מגיעה מעל זה, מפני שבדיקות זהות לעולם אינן מספקות מסלול או תשובת DNS.

1. צרו את רשומת האפליקציה ואמתו שמזהה הישות או הלקוח תואם למה שהאפליקציה שולחת.
2. רשמו את כתובת ה-URL המדויקת לקריאה חוזרת, כולל סכימה ופורט; פספוס קטן נכשל לאחר שהמשתמש מאמת את עצמו.
3. הקצו את המשתמשים או הקבוצות, ואז אמתו שההצהרות הנדרשות מונפקות.
4. אפשרו את נקודות הקצה של ספק הזהויות וגם את האפליקציה הפרטית, אחרת ההפניה לא תוכל להסתיים.

הקשר הדפדפן קובע אם ייעשה שימוש חוזר במושב קיים של הספק. לקוח מקורי שפותח את דפדפן המערכת יכול לחלוק את המצב הזה, ואילו תצוגה מוטמעת עם צנצנת קובצי Cookie משלה בדרך כלל לא יכולה. דפדפן חדש, חלונות פרטיים ופרופיל שני מתחילים מאפס, וזה צפוי ולא תצורת 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.

תקנו בקשות על ידי מציאת מי ביקש

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

אחר כך החליטו מה לשפר. אם הבקשה מגיעה מהאפליקציה, תקנו את רשומת הפדרציה שלה. אם היא מגיעה מהספק לפי מדיניות, תעדו את הדרישה. אם האפליקציה אינה נגישה לאחר התחברות מוצלחת, הניתוב של המנהרה הוא החשוד, מפני ש זהות ומסירת מנות נכשלות במקומות שונים ונראות דומות מנקודת המבט של המשתמש.