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