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