כניסה יחידה (SSO)

Last reviewed 2025-07-30 UTC

אתם יכולים להגדיר את החשבון שלכם ב-Cloud Identity או ב-Google Workspace כך שישתמשו בכניסה יחידה (SSO). כשמפעילים SSO, המשתמשים לא מתבקשים להזין סיסמה כשהם מנסים לגשת לשירותי Google. במקום זאת, הם מופנים אל ספק זהויות חיצוני (IdP) כדי לבצע אימות.

לשימוש ב-SSO יש כמה יתרונות:

• אתם משפרים את חוויית המשתמש כי המשתמשים יכולים להשתמש באישורים הקיימים שלהם כדי לבצע אימות, ולא צריכים להזין אישורים לעיתים קרובות.
• אתם מוודאים שספק הזהויות הקיים שלכם יישאר המערכת הרשמית לאימות משתמשים.
• אתם לא צריכים לסנכרן סיסמאות עם Cloud Identity או עם Google Workspace.

כדי להשתמש ב-SSO, למשתמש חייב להיות חשבון משתמש ב-Cloud Identity או ב-Google Workspace וזהות תואמת ב-IdP החיצוני. לכן, בדרך כלל משתמשים ב-SSO בשילוב עם מקור חיצוני מהימן שמקצה הרשאות למשתמשים ב-Cloud Identity או ב-Google Workspace באופן אוטומטי.

הערה: משתמשים עם הרשאות סופר-אדמין יכולים לעקוף את הכניסה באמצעות חשבון יחיד. כך סופר-אדמינים יכולים לגשת לחשבון גם אם הגדרת ה-SSO שגויה או אם ספק ה-IdP החיצוני לא זמין.

תהליך הכניסה היחידה (SSO)

‫Cloud Identity ו-Google Workspace תומכים ב-Security Assertion Markup Language ‏ (SAML) 2.0 לכניסה יחידה. ‫SAML הוא תקן פתוח להחלפת נתוני אימות והרשאה בין ספק זהויות (IdP) של SAML לבין ספקי שירות של SAML. כשמשתמשים ב-SSO ב-Cloud Identity או ב-Google Workspace, ספק הזהויות החיצוני הוא ספק הזהויות ב-SAML, ו-Google היא ספק השירות ב-SAML.

‫Google מטמיעה SAML 2.0 HTTP POST binding. הקישור הזה מציין איך מידע האימות מועבר בין ספק הזהויות של SAML לבין ספק השירות של SAML. בתרשים הבא מוצגת דוגמה לאופן הפעולה של התהליך הזה כשמשתמשים ב-SSO כדי לגשת למסוף Google Cloud .

1. מפנים את הדפדפן אל המסוף Google Cloud (או אל כל משאב אחר של Google שנדרש בו אימות).
2. מכיוון שעדיין לא עברת אימות, הדפדפן שלך מועבר אוטומטית אל דף הכניסה לחשבון Google במסוף Google Cloud .
3. מערכת הכניסה באמצעות חשבון Google מחזירה דף כניסה ומבקשת להזין את כתובת האימייל.
4. מזינים את כתובת האימייל ושולחים את הטופס.
5. מערכת הכניסה לחשבון Google מחפשת את חשבון Cloud Identity או Google Workspace שמשויך לכתובת האימייל שלכם.

6. מכיוון שהכניסה היחידה מופעלת בחשבון המשויך ב-Cloud Identity או ב-Google Workspace, מערכת הכניסה לחשבון Google מפנה את הדפדפן לכתובת ה-URL של ספק הזהויות החיצוני שהוגדר. לפני ההפניה, המערכת מוסיפה לכתובת ה-URL שני פרמטרים, RelayState ו-SAMLRequest.

   • העמודה RelayState מכילה מזהה שספק הזהויות החיצוני צפוי להעביר בחזרה מאוחר יותר.

   • ‫SAMLRequest מכיל את בקשת אימות SAML, מסמך XML שעבר דחיסה, קידוד base64 וקידוד כתובת URL. בצורה מפוענחת, בקשת אימות SAML נראית בדומה לדוגמה הבאה:

     <samlp:AuthnRequest
             ProviderName="google.com"
             IsPassive="false"
             AssertionConsumerServiceURL="https://www.google.com/a/example.com/acs"
             ...>
       <saml:Issuer xmlns:saml="...">google.com</saml:Issuer>
       <samlp:NameIDPolicy
             AllowCreate="true"
             Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
     </samlp:AuthnRequest>
     

   בדוגמה הזו, הבקשה מורה ל-IdP החיצוני לאמת את המשתמש, ליצור טענת נכוֹנוּת (assertion) של SAML עבור קהל היעד google.com ולפרסם אותה בשירות צרכן טענות הנכוֹנוּת (ACS) בכתובת https://www.google.com/a/example.com/acs.

   הדומיין שמוטמע בכתובת ה-URL של ACS‏ (example.com) תואם לדומיין הראשי של חשבון Google Workspace או Cloud Identity.

   אם משתמשים בתכונה של מנפיק ספציפי לדומיין כשמגדירים כניסה יחידה (SSO), המנפיק הוא google.com/a/DOMAIN במקום google.com, כאשר DOMAIN הוא הדומיין הראשי של חשבון Cloud Identity או Google Workspace.

   השלבים שספק ה-IdP החיצוני מבצע כדי לאמת את הזהות תלויים בספק ה-IdP ובהגדרות שלו. לדוגמה, יכול להיות שיוצג דו-שיח לכניסה, או שתתבקשו להשתמש באימות רב-שלבי או בטביעת אצבע. אחרי שמשלימים את השלבים האלה, תהליך חילופי הנתונים ב-SAML נמשך:

   

7. ספק ה-IdP החיצוני מחזיר דף HTML שנוצר במיוחד וגורם לדפדפן לשלוח באופן מיידי בקשת HTTP POST לכתובת ה-URL של ACS. הבקשה הזו מכילה שני פרמטרים:

   • ‫RelayState, שמכיל את הערך שהועבר במקור אל ספק ה-IdP בבקשת האימות של SAML.

   • ‫SAMLResponse, שמכיל את טענת הנכוֹנוּת (assertion) של SAML בקידוד base64. טענת הנכוֹנוּת (assertion) של SAML היא מסמך XML שמציין שה-IdP אימת את המשתמש בהצלחה. בטופס מפוענח, טענת הנכונות (assertion) של SAML נראית בערך כך:

     <samlp:Response ...>
       ...
       <Assertion x...>
         <Issuer>https://idp.example.org/</Issuer>
         <Signature ...>
           ...
         </Signature>
         <Subject>
           <NameID Format="...:nameid-format:emailAddress">[e-mail]</NameID>
           ...
         </Subject>
         <Conditions NotBefore="..." NotOnOrAfter="...">
           <AudienceRestriction>
             <Audience>google.com</Audience>
           </AudienceRestriction>
         </Conditions>
         <AttributeStatement>
           ...
         </AttributeStatement>
         <AuthnStatement AuthnInstant="..." ...>
           <AuthnContext>
             <AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
           </AuthnContext>
         </AuthnStatement>
       </Assertion>
     </samlp:Response>
     

   טענת הנכוֹנוּת (assertion) לדוגמה הזו הונפקה לקהל google.com (תואם למנפיק של בקשת האימות של SAML), ומצוין בה שספק ה-IdP‏ https://idp.example.org/ אימת את המשתמש [e-mail].

   הצהרת ה-SAML מכילה גם חתימה דיגיטלית. ספק הזהויות יוצר את החתימה הזו באמצעות המפתח הפרטי של אישור החתימה. המפתח הפרטי ידוע רק לספק הזהויות. המפתח הציבורי התואם הוא חלק מהגדרת ה-SSO ב-Cloud Identity או ב-Google Workspace, והוא משותף עם הכניסה לחשבון Google.

   טענת הנכוֹנוּת (assertion) של SAML מכילה גם חתימה דיגיטלית שמאפשרת לספק השירות של SAML לאמת את האותנטיות של טענת הנכוֹנוּת.

8. הדפדפן שולח את טענת הנכוֹנוּת (assertion) של SAML לנקודת הקצה של ACS ב-Google.

9. נקודת הקצה של ACS מאמתת את החתימה הדיגיטלית של הצהרת ה-SAML. הבדיקה הזו מתבצעת כדי לוודא שההצהרה מגיעה מ-IdP חיצוני מהימן ושלא בוצעו בה שינויים. בהנחה שהחתימה תקפה, נקודת הקצה של ACS מנתחת את תוכן הטענה, כולל אימות פרטי הקהל שלה וקריאת המאפיין NameID.

10. נקודת הקצה של ACS מחפשת את חשבון המשתמש שלכם על ידי התאמת NameID של טענת ה-SAML לכתובת האימייל הראשית של המשתמש. לאחר מכן, נקודת הקצה מתחילה סשן.

11. על סמך המידע שמקודד בפרמטר RelayState, נקודת הקצה קובעת את כתובת ה-URL של המשאב שאליו התכוונתם לגשת במקור, ואתם מופנים מחדש למסוף Google Cloud .

כניסה יזומה של IdP

התהליך שמתואר בקטע הקודם נקרא לפעמים כניסה לחשבון שמתחילה אצל ספק השירות, כי התהליך מתחיל אצל ספק השירות, שבמקרה של הדוגמה הקודמת הוא מסוף Google Cloud .

ב-SAML מוגדר גם תהליך חלופי שנקרא כניסה ביוזמת IdP, שמתחיל ב-IdP. ‫Google לא תומכת בתהליך הזה, אבל אפשר להשיג תוצאות דומות באמצעות כתובת ה-URL הבאה כדי להתחיל כניסה שמתבצעת על ידי ספק השירות:

https://www.google.com/a/DOMAIN/ServiceLogin?continue=https://console.cloud.google.com/

בדוגמה הזו, DOMAIN הוא הדומיין הראשי של חשבון Cloud Identity או Google Workspace.

אימות רב-שלבי

כדי להגן על חשבונות משתמשים מפני גישה לא מורשית, אתם יכולים לדרוש מהמשתמשים לספק גורם שני במהלך האימות. יש שתי דרכים להטמיע אימות רב-שלבי כשמשתמשים בכניסה יחידה (SSO):

1. אם ספק הזהויות החיצוני שלכם תומך באימות רב-שלבי, אתם יכולים להגדיר שהוא יבצע את האימות הרב-שלבי כחלק מתהליך הכניסה שמבוסס על SAML. במקרה כזה, לא נדרשות הגדרות נוספות ב-Cloud Identity או ב-Google Workspace.
2. אם ספק הזהויות שלכם לא תומך באימות רב-שלבי, אתם יכולים להגדיר את חשבון Cloud Identity או Google Workspace כך שיבצע אימות דו-שלבי מיד אחרי שהמשתמש מאומת על ידי ספק הזהויות החיצוני.

הערה: סופר-אדמינים יכולים לעקוף את הכניסה היחידה (SSO), ולכן כל אימות רב-גורמי שנאכף על ידי ספק הזהויות החיצוני לא חל על המשתמשים האלה. כדי להבטיח שהמשתמשים עם הרשאות סופר-אדמין יהיו מוגנים, צריך להפעיל אימות דו-שלבי עבור המשתמשים האלה.

Networking

בקישור להפניה אוטומטית של HTTP ב-SAML 2.0, ספק הזהויות וספק השירות לא מתקשרים ישירות. במקום זאת, כל התקשורת מועברת דרך הדפדפן של המשתמש, כמו שמוצג בדיאגרמה הבאה:

בהתאם לארכיטקטורה הזו, ספק הזהויות לא צריך להיות חשוף לאינטרנט, או אפילו להיות בעל גישה לאינטרנט, כל עוד המשתמשים יכולים לגשת אליו מהרשת הארגונית.

הגדרת ספק הזהויות החיצוני

ב-Cloud Identity וב-Google Workspace אפשר להגדיר כניסה יחידה באמצעות התכונות הבאות:

• פרופילים של SAML: אתם יכולים ליצור פרופיל SAML לכל ספק זהויות שאתם רוצים לשלב. לכל משתמש, קבוצה או יחידה ארגונית בחשבון Cloud Identity או Google Workspace, אתם מחליטים אם הם חייבים להשתמש ב-SSO ובאיזה פרופיל SAML הם חייבים להשתמש.

• פרופיל SAML מדור קודם (לשעבר פרופיל SSO ארגוני): אפשר להשתמש בפרופיל SAML מדור קודם כדי לבצע שילוב עם IdP יחיד. לכל משתמש, קבוצה או יחידה ארגונית בחשבון Cloud Identity או בחשבון Google Workspace, אתם מחליטים אם הם צריכים להשתמש ב-SSO או לא.

הדרך הנכונה להגדיר את ספק הזהויות תלויה בפרופילים של SAML שבהם אתם משתמשים או בפרופיל SAML מדור קודם. בטבלה הבאה מפורטות ההגדרות שבדרך כלל צריך להגדיר בספק זהויות חיצוני כדי להבטיח תאימות.

הגדרות אישיות	הגדרה נדרשת לפרופיל SAML מדור קודם	הגדרה נדרשת עבור פרופילי SAML	הערות
מזהה שם	כתובת האימייל הראשית של המשתמש	כתובת האימייל הראשית של המשתמש
פורמט למזהה שם	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress	urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
מזהה ישות	אם התכונה 'מנפיק ספציפי לדומיין' מופעלת: google.com/a/DOMAIN אם התכונה 'מנפיק ספציפי לדומיין' מושבתת (ברירת מחדל): google.com אם רוצים לשלב כמה חשבונות Google Workspace או Cloud Identity עם אותו IdP, צריך להשתמש בתכונה של הנפקת אישורים ספציפיים לדומיין. אחרת, משאירים אותה מושבתת.	מזהה ישות ייחודי של פרופיל ה-SAML. בהתאם לתאריך היצירה של פרופיל SAML, מזהה הישות הוא באחד מהפורמטים הבאים: https://accounts.google.com/samlrp/metadata?rpid=ID https://accounts.google.com/samlrp/ID
תבנית כתובת ה-URL של ACS (או כתובת ה-URL להפניה אוטומטית)	https://www.google.com/a/*	כתובת ה-URL הייחודית של ACS בפרופיל SAML. בהתאם לתאריך היצירה של פרופיל ה-SAML, כתובת ה-URL היא באחד מהפורמטים הבאים: https://accounts.google.com/samlrp/acs?rpid=ID https://accounts.google.com/samlrp/ID/acs
בקשת חתימה	מושבת	מושבת	בקשות אימות SAML שמונפקות על ידי הכניסה לחשבון Google אף פעם לא חתומות
חתימה על טענת נכוֹנוּת (assertion)	מופעל	מופעל	כדי לאפשר לכניסה לחשבון Google לאמת את האותנטיות של הצהרות SAML, צריך לחתום עליהן. כשמגדירים SSO במסוף Admin, צריך להעלות את המפתח הציבורי של זוג המפתחות לחתימת טוקנים.
הצפנת הצהרה	מושבת	מושבת
האלגוריתם של החתימה	RSA-SHA256	RSA-SHA256	לפעמים מקצרים את RSA-SHA256 ל-RS256

הערה: יכול להיות שחלק מההגדרות יקבלו שמות שונים או שלא יהיה אפשר להגדיר אותן בכלל, בהתאם לספק ה-IdP שבו אתם משתמשים.

המאמרים הבאים

• כדאי לעיין בדוגמאות לארכיטקטורות לשילוב עם IdP חיצוני.
• איך מגדירים הקצאת חשבונות ו-SSO באמצעות Microsoft Entra ID או Active Directory
• מומלץ לקרוא את השיטות המומלצות לאיחוד Google Cloud עם ספק זהויות חיצוני.

שותפים ביצירת התוכן

מחבר: Johannes Passing | Cloud Solutions Architect