כניסה יחידה (SSO) מאפשרת למשתמשים להיכנס להרבה אפליקציות ארגוניות בענן באמצעות קבוצה אחת של פרטי כניסה. Workspace (ו-Google Cloud Platform) תומכים ב-SSO מספקי זהויות (IdP) של צד שלישי.
Workspace תומך בפרוטוקולי SSO של SAML ו-OIDC.
כדי להשתמש ב-SSO, צריך להגדיר פרופילי SSO ואז להקצות אותם לקבוצות משתמשים או ליחידות ארגוניות. כך אפשר לתמוך בכמה ספקי זהויות ולבדוק הגדרות של כניסה יחידה (SSO). זו המערכת המומלצת ל-SSO. פרופיל SSO מדור קודם לארגונים זמין גם הוא (ל-SAML בלבד).
כניסה יחידה זמינה גם במכשירי Chrome. פרטים נוספים מופיעים במאמר בנושא הגדרת כניסה יחידה (SSO) שמבוססת על SAML למכשירי Chrome.
אימות נוסף אחרי כניסה יחידה
כשמגדירים SSO, משתמשים שנכנסים לחשבון שלהם ב-IdP מצד שלישי יכולים לגשת לאפליקציות של Google בלי אימות נוסף, למעט במקרים הבאים:
- גם אם המשתמשים כבר נכנסו לספק הזהויות שלהם, Google תבקש מהם לפעמים לאמת את הזהות שלהם כאמצעי אבטחה נוסף. למידע נוסף (ולפרטים על השבתת האימות הזה, אם יש צורך), אפשר לעבור למאמר בנושא הבנת כניסה מאובטחת באמצעות SAML.
- אתם יכולים להגדיר אימות דו-שלבי נוסף למשתמשים שניגשים לשירותי Google. בדרך כלל, כש-SSO מופעל, האימות הדו-שלבי לא נדרש. מידע נוסף זמין במאמר בנושא הפעלת אתגרים באמצעות SSO.
הסבר על כניסה יחידה (SSO) מבוססת-SAML שמופעלת על ידי שותף
איור 1 מציג את התהליך שבו משתמש נכנס לאפליקציית Google, כמו Gmail, דרך שירות SSO מבוסס SAML שמופעל על ידי שותף. הרשימה הממוספרת שמופיעה אחרי התמונה מפרטת כל שלב.
חשוב: לפני שהתהליך הזה מתבצע, השותף צריך לספק ל-Google את כתובת ה-URL של שירות ה-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. רוב ספקי הזהויות תומכים בסנכרון עם Google. הוראות ההגדרה מופיעות במסמכי התיעוד של ספק הזהויות.
כניסה יחידה (SSO) ו-LDAP מאובטח
פרוטוקול LDAP מאובטח דורש סיסמה של Google ולא תואם ל-SSO.