כניסה יחידה (SSO) מאפשרת למשתמשים להיכנס להרבה אפליקציות ארגוניות בענן באמצעות מערכת אחת של פרטי כניסה. Workspace (ו-Google Cloud Platform) תומכים ב-SSO מספקי זהויות (IdP) של צד שלישי.
Workspace תומך בפרוטוקולי SAML ו-OIDC ל-SSO.
כדי להשתמש ב-SSO, צריך להגדיר פרופילי SSO ואז להקצות אותם לקבוצות משתמשים או ליחידות ארגוניות. כך אפשר לתמוך בכמה ספקי זהויות ולבדוק הגדרות של כניסה יחידה (SSO). זו המערכת המומלצת ל-SSO. פרופיל ה-SSO מדור קודם לארגונים זמין גם הוא (ל-SAML בלבד).
התכונה 'כניסה יחידה' זמינה גם במכשירי Chrome. פרטים נוספים מופיעים במאמר בנושא הגדרת כניסה יחידה (SSO) המבוססת על SAML למכשירי Chrome.
אימות נוסף אחרי כניסה יחידה
כשמגדירים SSO, משתמשים שנכנסים לחשבון שלהם ב-IdP מצד שלישי יכולים לגשת לאפליקציות של Google בלי אימות נוסף, למעט במקרים הבאים:
- גם אם הם כבר נכנסו ל-IdP שלהם, לפעמים Google תבקש מהם לאמת את הזהות שלהם כאמצעי אבטחה נוסף. מידע נוסף (כולל פרטים על השבתת האימות הזה, אם יש צורך) זמין במאמר בנושא הבנת כניסה מאובטחת באמצעות SAML.
- אתם יכולים להגדיר אימות דו-שלבי נוסף למשתמשים שניגשים לשירותי Google. בדרך כלל, כשמופעלת כניסה יחידה, האימות הדו-שלבי לא נדרש. מידע נוסף זמין במאמר בנושא הפעלת אתגרים באמצעות SSO.
הסבר על כניסה יחידה (SSO) מבוססת-SAML שמופעלת על ידי שותף
איור 1 מציג את התהליך שבו משתמש נכנס לאפליקציית Google, כמו Gmail, דרך שירות SSO מבוסס SAML שמופעל על ידי שותף. הרשימה הממוספרת שמופיעה אחרי התמונה מפרטת כל שלב.
חשוב: לפני שהתהליך הזה מתבצע, השותף צריך לספק ל-Google את כתובת האתר של שירות ה-SSO שלו ואת המפתח הציבורי ש-Google צריכה להשתמש בו כדי לאמת את תגובות SAML.
איור 1: מוצג תהליך הכניסה ל-Google באמצעות שירות SSO מבוסס-SAML.
התמונה הזו מדגימה את השלבים הבאים.
- המשתמש מנסה לגשת לאפליקציית Google באירוח, כמו Gmail, יומן Google או שירות אחר של Google.
- Google יוצרת בקשת אימות SAML, שמקודדת ומוטמעת בכתובת ה-URL של שירות ה-SSO של השותף. הפרמטר RelayState שמכיל את כתובת ה-URL המקודדת של אפליקציית Google שהמשתמש מנסה להגיע אליה מוטמע גם בכתובת ה-URL של ה-SSO. הפרמטר RelayState הוא מזהה אטום שמועבר בחזרה ללא שינוי או בדיקה.
- Google שולחת הפניה אוטומטית לדפדפן של המשתמש. כתובת ה-URL להפניה אוטומטית כוללת את בקשת האימות המקודדת של SAML, שצריך לשלוח לשירות ה-SSO של השותף.
- הדפדפן מפנה לכתובת ה-URL של ה-SSO.
- השותף מפענח את בקשת SAML ומחלץ את כתובת ה-URL של ACS (Assertion Consumer Service) של Google ואת כתובת היעד של המשתמש (פרמטר RelayState).
- השותף מאמת את המשתמש. שותפים יכולים לאמת משתמשים על ידי בקשת פרטי כניסה תקינים או על ידי בדיקה של קובצי Cookie תקינים של סשנים.
- השותף יוצר תגובת SAML שמכילה את שם המשתמש של המשתמש המאומת. בהתאם למפרט SAML v2.0, התגובה הזו חתומה בחתימה דיגיטלית עם המפתחות הציבוריים והפרטיים של השותף מסוג DSA/RSA.
- השותף מקודד את תגובת ה-SAML ואת הפרמטר RelayState ומחזיר את המידע הזה לדפדפן של המשתמש. השותף מספק מנגנון שמאפשר לדפדפן להעביר את המידע הזה אל ACS של Google. לדוגמה, השותף יכול להטמיע את תגובת SAML ואת כתובת היעד בטופס, ולספק לחצן שהמשתמש יכול ללחוץ עליו כדי לשלוח את הטופס ל-Google. השותף יכול גם לכלול קוד JavaScript בדף ששולח את הטופס ל-Google.
- הדפדפן שולח תגובה לכתובת אתר של ACS. מערכת ACS של Google מאמתת את תגובת SAML באמצעות המפתח הציבורי של השותף. אם האימות של התגובה יצליח, ACS יפנה את המשתמש לכתובת היעד.
- המשתמש מחובר לאפליקציית Google.
סנכרון חשבונות משתמשים בין ספק הזהויות לבין Google
כדי לפשט את ניהול מחזור החיים של המשתמשים, רוב הארגונים שמשתמשים ב-SSO גם מסנכרנים את ספריית המשתמשים שלהם מ-IdP ל-Google. אחרי שמגדירים את הסנכרון, משתמשים חדשים (או משתמשים שנמחקו) בצד של ספק ה-IdP מתווספים אוטומטית כמשתמשי Workspace או נמחקים מהמערכת. Directory Sync של Google תומך ב-Active Directory וב-Entra ID. רוב ספקי ה-IdP תומכים בסנכרון עם Google. הוראות ההגדרה מופיעות במסמכי התיעוד של ספק ה-IdP.
כניסה יחידה (SSO) ו-LDAP מאובטח
פרוטוקול LDAP מאובטח דורש סיסמה של Google ולא תואם ל-SSO.