- באיזו גרסה של SAML תומך ה-API של SSO?
- האם SSO ב-SAML פועל עם POP3 או IMAP?
- האם כניסת SSO באמצעות SAML פועלת עם פיד Atom של Gmail?
- האם כניסה יחידה (SSO) שמבוססת על SAML פועלת עם AuthSub?
- האם אפשר להשתמש ב-RSA במקום ב-DSA להטמעה של כניסה יחידה (SSO)?
- איך אפשר ליצור את אישור האימות שנדרש ל-SSO?
- אם בדומיין שלנו מוגדרת כניסה יחידה (SSO), עדיין אפשר להתחבר ישירות ל-Google?
- איך אפשר למחוק את קובץ ה-Cookie הזמני שמזהה משתמש במהלך סשן בדפדפן (למשל, אחרי התנתקות)?
- למה כתובת ה-URL לשינוי הסיסמה לא עובדת?
- למה טופס ה-HTML של SAMLResponse פועל ב-Firefox אבל לא ב-Internet Explorer?
- איך אפשר לאפשר למשתמשים לראות את דף הפתיחה של השותף בלי אימות?
- מהו מאפיין הנמען שנדרש בתגובת SAML?
- איך אפשר לוודא שספק הזהויות של הצד השלישי מציין את מאפיין הנמען הנכון?
אם מוגדר SSO, המשתמשים יכולים לאמת את הזהות שלהם באמצעות כתובת ה-URL להתחברות ללוח הבקרה של האדמין?
מה המשמעות של הודעת השגיאה הזו: "אין אפשרות לגשת לחשבון הזה כי לא ניתן לאמת את פרטי הכניסה"?
באיזו גרסה של SAML תומך ה-API של SSO?
בשלב הזה אנחנו תומכים ב-SAML גרסה 2.0. בכתובת http://www.oasis-open.org/specs/index.php#samlv2.0 אפשר למצוא פרטים על תקן SAML v2.0.
האם SSO ב-SAML פועל עם POP3 או IMAP?
לא, SAML פועל רק עם אפליקציות האינטרנט של Google Workspace.
האם כניסת SSO באמצעות SAML פועלת עם עדכון Atom של Gmail?
לא, פיד Atom של Gmail משתמש באימות בסיסי של HTTP.
האם כניסה יחידה (SSO) ב-SAML עובדת עם AuthSub?
כן, SAML עובד עם AuthSub.
האם אפשר להשתמש ב-RSA במקום ב-DSA להטמעה של כניסה יחידה (SSO)?
כן, אתם יכולים לבחור להשתמש באלגוריתם הצפנה מסוג RSA או DSA. אנחנו מקבלים את שניהם.
איך אפשר ליצור את אישור האימות שנדרש ל-SSO?
אפשר ליצור אישורי X509 באמצעות הפקודה openssl. פרטים נוספים זמינים במאמר יצירת מפתחות ואישורים ל-SSO.
אם בדומיין שלנו מוטמעת כניסה יחידה (SSO), האם עדיין אפשר להתחבר ישירות ל-Google?
לא, כשמטמיעים כניסה יחידה (SSO), משתמשי הקצה בדומיין לא יכולים להתחבר ישירות ל-Google. סופר-אדמינים עדיין יכולים להיכנס ללוח הבקרה של Google (למשל, http://www.google.com/a/example.com).
איך אפשר למחוק את קובץ ה-Cookie הזמני שמזהה משתמש במהלך סשן בדפדפן (למשל, אחרי התנתקות)?
אחרי אימות מוצלח באמצעות SAML, Google מגדירה קובץ Cookie זמני כדי לזהות את הסשן של המשתמש. כשהמשתמש מתנתק באופן מפורש (למשל, על ידי לחיצה על כפתור ההתנתקות), צריך להשמיד את קובץ ה-cookie הזה. אם ההטמעה שלכם כוללת ניהול סשנים מתמשכים (פונקציונליות של "זכור אותי במחשב הזה"), יכול להיות שתצטרכו לשלוט באופן ובמועד שבהם קובץ ה-Cookie הזה נמחק. אחרי היציאה מהחשבון, Google מפנה ל-servlet של היציאה מהחשבון. ב-servlet של היציאה מהחשבון, אתם יכולים להציג למשתמש כמה אפשרויות שיקבעו אם קובץ ה-Cookie הזמני יימחק או לא.
למה כתובת ה-URL לשינוי הסיסמה לא פועלת?
שינויים בכתובת ה-URL לשינוי הסיסמה בהגדרות ה-SSO נכנסים לתוקף תוך כשעה.
למה טופס ה-HTML של SAMLResponse פועל ב-Firefox אבל לא ב-Internet Explorer?
יכול להיות שהסיבה לכך היא ש-Internet Explorer מפרש באופן שגוי את RelayState. Internet Explorer מפרש את "<mpl" בתור "<mpl". כדי למנוע את זה, צריך להוסיף תווי בריחה (escape) לתווים המיוחדים של XML ב-RelayState. משנים את { &, <, >, ', " } ל- { &, <, >, ', " }.
איך אפשר לאפשר למשתמשים לראות את דף הפתיחה של השותף בלי לבצע אימות?
בנושא הזה בקבוצת הדיון יש דוגמה ל-SAMLResponse.
מהו מאפיין הנמען שנדרש בתגובת ה-SAML?
לפי סעיף 4.1.4.2 של מפרט הפרופילים של SAML 2.0, המאפיין Recipient צריך להיות זהה לכתובת ה-URL של Assertion Consumer Service (ACS). הוא נמצא כאן:
<samlp:Response ...>
<saml:Assertion ...>
<saml:Subject>
<saml:NameID ...>user@domain.com</saml:NameID>
<saml:SubjectConfirmation ...>
<saml:SubjectConfirmationData Recipient="https://www.google.com/a/domain.com/acs" .../>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:Assertion>
</samlp:Response>
בשאלות שבהמשך מוסבר איך להוסיף את הנמען לתגובת SAML.
איך מוודאים שספק הזהויות של הצד השלישי מציין את מאפיין הנמען הנכון?
אם ספק הזהויות המסחרי או בקוד פתוח תומך ב-SAML 2.0, הוא כבר אמור לציין את מאפיין הנמען הנכון. אם מוצגת אחת מהודעות השגיאה שלמעלה, סימן שהמאפיין Recipient שגוי. במקרה כזה, צריך לפנות לספק או למנהל התחזוקה של התוכנה ולשלוח להם את הקישור לדף הזה.
האם המשתמשים שלי יכולים לאמת את עצמם באמצעות כתובת ה-URL להתחברות ללוח הבקרה של האדמין?
כן. כניסה יחידה (SSO) שמבוססת על SAML מאפשרת לכם להעביר את סמכות הכניסה ל-Google Workspace לתוכנה של ספק הזהויות שלכם (לדוגמה, פורטל כניסה קיים). התוכנה שלכם שולטת באימות של חשבונות המשתמשים ומנהלת אותו, ו-Google Workspace תפנה ניסיון התחברות לפורטל ה-SSO שלכם. אבל חשוב לזכור שהאדמינים עדיין יוכלו לנהל את השירותים האלה באמצעות כתובת ה-URL להתחברות של האדמין במסוף Google Admin (https://www.google.com/a/example.com). כך תהיה לכם גמישות אם תהיה בעיה בפורטל ה-SSO או אם יהיה צורך לעדכן אותו.
מה המשמעות של הודעת השגיאה: "לא ניתן לגשת לשירות הזה כי בקשת הכניסה לא הכילה מידע על הנמען"?
המשמעות היא שבתגובת ה-SAML חסר מאפיין Recipient (נמען) שנדרש.
מה המשמעות של הודעת השגיאה הזו: "אין לך גישה לשירות הזה כי בקשת ההתחברות שלך כוללת פרטי נמען לא חוקיים"?
המשמעות היא שהמאפיין Recipient בתגובת SAML לא תואם לכתובת ה-URL של Assertion Consumer Service (ACS).
מה המשמעות של הודעת השגיאה הזו: "אין אפשרות לגשת לחשבון הזה כי לא ניתן לאמת את פרטי הכניסה"?
בדרך כלל זה אומר שהמפתח הפרטי שמשמש לחתימה על SAMLResponse לא תואם לאישור של המפתח הציבורי ששמור ב-Google Workspace. צריך להעלות את האישור בהגדרות ה-SSO בלוח הבקרה ולנסות שוב.