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