מוצג המסמך של Apigee Edge.
עוברים אל
מסמכי תיעוד של Apigee X. מידע
SAML מאפשר לאדמינים ספציפיים לשלוט באופן שבו כל חברי הארגון מבצעים אימות כשמשתמשים ב-Apigee Edge על ידי הענקת גישה לשרת של כניסה יחידה (SSO). שימוש ב-SAML עם Edge, אפשר לתמוך ב-SSO לממשק המשתמש ול-API של Edge בנוסף לכל שירות אחר שאתם מספקים ותומך גם ב- SAML.
כדי להפעיל SSO באמצעות SAML לפורטלים משולבים, כדאי לעיין במאמר הגדרה של ספק הזהויות ב-SAML.
הסבר על ניהול אזורי זהויות ב-Edge
אזור זהות הוא תחום אימות שמגדיר את ספקי הזהויות שמשמשים לאימות ותצורה מותאמת אישית של חוויית הרישום והכניסה של המשתמש. רק כשמשתמשים מבצעים אימות באמצעות ספק הזהויות, הם יכולים לגשת לישויות בהיקף של אזור הזהות.
Apigee Edge תומך בסוגי האימות שמתוארים בטבלה הבאה.
| סוג אימות | תיאור |
| ברירת מחדל | יוצרים חשבון Apigee Edge ונכנסים לממשק המשתמש של Edge באמצעות שם משתמש וסיסמה. כשמשתמשים ב-Edge API, משתמשים בפרטי הכניסה האלה באמצעות אימות בסיסי של HTTP כדי לאשר קריאות. |
| SAML | שפת הסימון של טענת האבטחה (SAML) היא פרוטוקול סטנדרטי לסביבות של כניסה יחידה (SSO). אימות SSO באמצעות SAML מאפשר להיכנס ל-Apigee Edge באמצעות פרטי הכניסה הקיימים שלכם, בלי שתצטרכו ליצור חשבונות חדשים. |
כדי לתמוך באימות SAML, יוצרים אזור זהות חדש ומגדירים ספק זהויות של SAML, כפי שמתואר במאמר הפעלת SAML.
היתרונות של אימות SAML
לאימות באמצעות SAML יש מספר יתרונות. אם תשתמשו ב-SAML, תוכלו:
- שליטה מלאה בניהול המשתמשים: חיבור שרת ה-SAML של החברה ל-Edge. כשמשתמשים עוזבים את הארגון וניהול ההקצאות שלהם מבוטל באופן מרוכז, הגישה שלהם ל-Edge נדחית באופן אוטומטי.
- שליטה באופן שבו המשתמשים מבצעים אימות כדי לגשת ל-Edge: בוחרים סוגי אימות שונים לארגונים של Edge.
- בקרה על מדיניות האימות: ספק ה-SAML שלכם עשוי לתמוך כללי מדיניות האימות שמתאימים יותר לסטנדרטים של הארגון.
- מעקב אחרי כניסות, התנתקות, ניסיונות התחברות כושלים ופעילויות בסיכון גבוה בפריסה של Edge.
לתשומת ליבכם
לפני שמחליטים להשתמש ב-SAML, קחו בחשבון את הדרישות הבאות:
- משתמשים קיימים: צריך להוסיף את כל המשתמשים הקיימים בארגון ל-SAML ספק הזהויות.
- פורטל: אם משתמשים בפורטל מפתחים מבוסס Drupal, הפורטל משתמש ב-OAuth כדי לגשת ל-Edge וייתכן שיהיה צורך להגדיר אותו מחדש כדי להשתמש בו.
- האימות הבסיסי יושבת: צריך להחליף את האימות הבסיסי ב-OAuth בכל החשבונות הבאים את הסקריפטים שלך.
- צריך לשמור על הפרדה בין OAuth לבין SAML: אם אתם משתמשים גם ב-OAuth 2.0 וגם ב-SAML, חייבים להשתמש בסשנים נפרדים בטרמינל לזרימת OAuth 2.0 ולתהליך SAML.
איך SAML פועל עם Edge
מפרט SAML מגדיר שלוש ישויות:
- חשבון משתמש (משתמש בממשק המשתמש של Edge)
- ספק שירות (Edge SSO)
- ספק זהויות (מחזיר טענת נכוֹנוּת (assertion) של SAML)
כש-SAML מופעל, חשבון המשתמש (משתמש בממשק המשתמש של Edge) מבקש גישה לספק השירות (העברת SSO). Edge SSO (בתפקידו כספק שירות של SAML) לאחר מכן מבקש ומקבל טענת נכוֹנוּת (assertion) של הזהות מספק הזהויות של SAML ומשתמשת בטענה הזו כדי ליצור את OAuth 2.0 נדרש אסימון כדי לגשת לממשק המשתמש של Edge. המשתמשים יופנו לממשק המשתמש של Edge.
התהליך מוצג למטה:
בתרשים הזה:
- המשתמש מנסה להיכנס לממשק המשתמש של Edge על ידי שליחת בקשה לדומיין ההתחברות
SSO, כולל שם התחום. לדוגמה,
https://zonename.login.apigee.com - בקשות לא מאומתות אל
https://zonename.login.apigee.comיופנו לספק הזהויות ב-SAML של הלקוח. לדוגמה:https://idp.example.com. - אם הלקוח לא מחובר לספק הזהויות, הוא יתבקש להתחבר אינץ'
- ספק הזהויות של SAML מאומת על המשתמש. ספק הזהויות ב-SAML יוצרת ומחזירה טענת נכוֹנוּת (assertion) של SAML 2.0 ל-Edge SSO.
- SSO ב-Edge מאמת את טענת הנכוֹנוּת (assertion), מחלץ את זהות המשתמש בטענת הנכוֹנוּת (assertion), יוצר
אסימון האימות מסוג OAuth 2.0 לממשק המשתמש של Edge, ומפנה את המשתמשים לממשק המשתמש הראשי של Edge
דף ב:
https://zonename.apigee.com/platform/orgName
כאשר orgName הוא השם של ארגון Edge.
מידע נוסף זמין במאמר גישה ל-Edge API באמצעות SAML.