במאמר הזה מוסבר איך להשתמש בזהויות חיצוניות עם Identity-Aware Proxy (IAP) במקום בחשבונות Google.
סקירה כללית
IAP שולט בגישה לאפליקציות ולמשאבים שלכם. הוא משתמש בזהות המשתמש ובהקשר של הבקשה כדי לקבוע אם המשתמש צריך לקבל גישה. IAP הוא אבן בניין של Chrome Enterprise Premium, פתרון אבטחה לארגונים שמאפשר לעובדים לעבוד מרשתות לא מהימנות בלי להשתמש ב-VPN.
כברירת מחדל, IAP משתמש ב-Google Identity וב-IAM. במקום זאת, אתם יכולים להשתמש ב-Identity Platform כדי לאמת משתמשים באמצעות מגוון רחב של ספקי זהויות חיצוניים, כמו:
אימייל/סיסמה
OAuth (Google, Facebook, Twitter, GitHub, Microsoft וכו')
SAML
OIDC
מספר טלפון
בהתאמה אישית
אנונימי
האפשרות הזו שימושית אם האפליקציה שלכם כבר משתמשת במערכת אימות חיצונית, ואין אפשרות מעשית להעביר את המשתמשים לחשבונות Google.
Multi-tenancy
במקור, מודל ריבוי הדיירים של Identity Platform תוכנן לתרחישי B2B, שבהם חברה אחת מוכרת שירות לחברות אחרות. במקרים כאלה, מפתחים בדרך כלל רוצים להפריד בין קבוצות משתמשים למאגרים מבודדים. המאגרים האלה נקראים דיירים.
נבחן את דיאגרמת הקשרים הבאה:
בדוגמה הזו, Acme היא יצרנית רכב (הסוכן) שמשתמשת ב-Identity Platform כדי לספק שירות לסוכנויות (הדיירים). הסוכנויות האלה מספקות שירותים ללקוחות, לעובדים ולקבלנים שלהן. למרות שהשירות שייך ליצרן, כל סוכנות יכולה להשתמש בקבוצה משלה של ספקי זהויות לצורך אימות. הסשנים והנתונים של המשתמשים מוגדרים ברמת הדייר, כך שאם למשתמש יש קשרים עם כמה סוכנויות, כל אחת מהן מטופלת בנפרד.
בהתאם לתרחיש לדוגמה, יש כמה דרכים לבנות את היררכיית הדיירים.
אין דיירים (tenants)
אתם צריכים להשתמש ב-multi-tenancy רק אם אתם צריכים לבודד משאבים. הדרישה הזו לא קיימת בכל האפליקציות. לדוגמה, אם יש לכם אפליקציה אחת ב-App Engine ואתם רוצים לחסום את הגישה לכל המשתמשים מחוץ לרשת שלכם, אין צורך בריבוי דיירים. כברירת מחדל, ב-Identity Platform המשתמשים נשמרים ומאומתים בכל פרויקט בנפרד, כך שבמקרה הזה אין צורך בהגדרות נוספות.
דוגמה נוספת היא תאגיד עם כמה חברות בת. גם אם לכל חברת בת יש מערכת אימות מנוהלת משלה (באמצעות OIDC או SAML), כל העובדים עשויים לחלוק את אותן הטבות ברמה גבוהה, כמו שירותי בריאות, חופשות ושכר. במקרה כזה, מספיק לבצע אימות ברמת הפרויקט.
דייר אחד לכל משאב
כברירת מחדל, אסימונים של Identity Platform שלא שייכים לדייר תקפים ברמת הפרויקט. באופן תיאורטי, זה אומר שמשתמש יכול לבצע אימות באמצעות משאב IAP אחד, ואז להשתמש באסימון כדי לגשת לשירות אחר באותו פרויקט. זהו סיכון אבטחה.
כדי למנוע דליפת אסימונים, צריך לבודד כל IAP על ידי הקצאת דייר משלו. אסימונים שנוצרו בהקשר של דייר ספציפי תקפים רק לאותו דייר. אם המשתמש ינסה לגשת למשאב אחר של IAP שמשתמש בדייר אחר, הוא יתבקש לבצע אימות מחדש.
כמה דיירים לכל משאב
למשאב IAP אחד יכולים להיות כמה דיירים משויכים.
כשמשתמש ניגש למשאב, יש כמה אפשרויות לקבוע באיזה דייר להשתמש. לדוגמה, אפשר לבקש מהמשתמש להזין קודם את כתובת האימייל שלו, ואז לאתר באופן פרוגרמטי דייר שתואם לדומיין של כתובת האימייל. לחלופין, אפשר להציג ממשק משתמש שמפרט את כל הדיירים החוקיים ולבקש מהמשתמש לבחור אחד.
משתמשים יכולים להשתייך לכמה דיירים עם רמות גישה שונות. אי אפשר להשתמש ב-IAM כדי לנהל את בקרת הגישה עם זהויות חיצוניות, אבל אסימון ה-JSON לאימות אינטרנטי (JWT) שנוצר על ידי IAP נושא את ההצהרות מהאסימון של מזהה Identity Platform, והאפליקציה יכולה לסנן את הגישה על סמך ההצהרות האלה.
דוגמה לתרחיש של ריבוי דיירים היא חברה שמספקת הטבות לעובדים, ויש לה הרבה לקוחות שמשתמשים בפורטל אינטרנט אחד. כשהמשתמשים נכנסים לפורטל, הם קודם בוחרים את החברה שלהם (הדייר) ואז מאמתים את הזהות שלהם באמצעות הספק שהמעסיק משתמש בו, עם פרטי הכניסה הארגוניים שלהם.