- באיזו גרסה של SAML תומך ה-SSO API?
- האם SAML SSO פועל עם POP3 או IMAP?
- האם כניסת SSO באמצעות SAML פועלת עם פיד ה-Atom של Gmail?
- האם כניסה יחידה (SSO) שמבוססת על SAML פועלת עם AuthSub?
- האם אפשר להשתמש ב-RSA במקום ב-DSA להטמעה של כניסה יחידה?
- איך אפשר ליצור את אישור האימות שנדרש ל-SSO?
- אם בדומיין שלנו מוגדר SSO, האם עדיין אפשר להיכנס ל-Google ישירות?
- איך אפשר למחוק קובץ Cookie של סשן לא קבוע שמזהה משתמש במהלך סשן בדפדפן (לדוגמה, אחרי התנתקות)?
- למה כתובת ה-URL לשינוי הסיסמה לא פועלת?
- למה טופס ה-HTML של SAMLResponse פועל ב-Firefox אבל לא ב-Internet Explorer?
- איך אפשר לאפשר למשתמשים לראות את דף הפתיחה של השותף בלי לבצע אימות?
- מהו מאפיין הנמען שנדרש בתגובת SAML?
- איך מוודאים שספק הזהויות מצד שלישי מציין את מאפיין הנמען הנכון?
האם משתמשים יכולים לאמת את עצמם באמצעות כתובת ה-URL להתחברות למרכז השליטה לאדמינים אם מוגדר SSO?
מה המשמעות של הודעת השגיאה: "אין אפשרות לגשת לשירות מכיוון שבקשת ההתחברות שלך לא מכילה פרטי נמען"?
באיזו גרסה של SAML תומך ה-API של SSO?
נכון לעכשיו, אנחנו תומכים ב-SAML גרסה 2.0. פרטים על תקן SAML v2.0 זמינים בכתובת http://www.oasis-open.org/specs/index.php#samlv2.0.
האם אפשר להשתמש ב-SAML SSO עם POP3 או IMAP?
לא, SAML פועל רק עם אפליקציות האינטרנט של Google Workspace.
האם אפשר להשתמש ב-SAML SSO עם פיד Atom של Gmail?
לא, פיד ה-Atom של Gmail משתמש באימות בסיסי של HTTP.
האם כניסה יחידה (SSO) ב-SAML פועלת עם AuthSub?
כן, SAML פועל עם AuthSub.
האם אפשר להשתמש ב-RSA במקום ב-DSA להטמעה של כניסה יחידה?
כן, אפשר לבחור להשתמש באלגוריתם ההצפנה 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 של הסשן יימחק או לא.
למה כתובת האתר לשינוי סיסמה לא פועלת?
שינויים בכתובת האתר לשינוי סיסמה בהגדרות ה-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, מאפיין הנמען צריך להיות שווה לכתובת ה-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, הוא כבר אמור לציין את מאפיין הנמען הנכון. אם מוצגת אחת מהודעות השגיאה שלמעלה, המשמעות היא שהמאפיין 'נמען' שגוי. במקרה כזה, צריך לפנות לספק או למתחזק של התוכנה ולשלוח להם את הקישור לדף הזה.
האם המשתמשים שלי יכולים לאמת את עצמם באמצעות כתובת ה-URL לכניסה לאמצעי בקרה לאדמינים באמצעות SSO?
כן. כניסה יחידה (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 בלוח הבקרה ולנסות שוב.