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