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

אתם יכולים להגדיר את חשבון 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)

שירותי Cloud Identity ו-Google Workspace תומכים ב-Security Assertion Markup Language ‏(SAML) 2.0 לכניסה יחידה (SSO). ‫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.

   הדומיין שמוטמע בכתובת אתר של 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 לכתובת אתר של 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">bob@example.org</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/ אימת את המשתמש bob@example.org.

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

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

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

9. נקודת הקצה של ACS מאמתת את החתימה הדיגיטלית של הצהרת ה-SAML. הבדיקה הזו מתבצעת כדי לוודא שהטענה מגיעה מ-IdP חיצוני מהימן ושלא בוצעו בה שינויים. בהנחה שהחתימה תקפה, נקודת הקצה של ACS מנתחת את תוכן טענת הנכוֹנוּת (assertion), כולל אימות פרטי הקהל שלה וקריאת המאפיין 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 כך שיתבצע אימות דו-שלבי מיד אחרי שהמשתמש יאומת על ידי ספק הזהויות החיצוני.

Networking

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

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

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

בעזרת התכונות הבאות של Cloud Identity ו-Google Workspace, אתם יכולים להגדיר כניסה יחידה (SSO):

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

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

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

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

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

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

מחבר: Johannes Passing | Cloud Solutions Architect