כברירת מחדל, שירות החשבונות של Google שאפשר לגשת אליו מבחוץ מטפל באימות של חשבונות Google. כשמשתמש לא מאומת מבקר בדף של Google שנדרש בו אימות, טופס הכניסה של Google מבקש את כתובת האימייל והסיסמה של המשתמש. אחרי שהמשתמש שולח את כתובת האימייל והסיסמה שלו, אימות Google מוודא שפרטי הכניסה שהוזנו נכונים. אם פרטי הכניסה נכונים, האימות של Google מגדיר את קובצי ה-Cookie של הכניסה של המשתמש.
חלק מהארגונים משתמשים במודל מתוחכם יותר שבו ספק זהויות של צד שלישי (IdP) מטפל באימות. אימות Google תומך במודל הזה באמצעות פרוטוקול Security Assertion Markup Language (SAML), שהוא תקן בתעשייה. אדמין יכול להגדיר דומיין לשימוש באימות SAML.
קבלת הסיסמה של המשתמש
מערכת ChromeOS צריכה לזהות את הסיסמה שהמשתמש הזין במהלך הכניסה כדי:
- הצפנה של נתוני המשתמש שמאוחסנים בכונן הדיסק.
- הגנה על מסך הנעילה.
- הפעלת התחברות במצב אופליין כשאין גישה לרשת.
כשמשתמשים ב-SAML, הסיסמה לא מוזנת ישירות בתיבת דו-שיח של מערכת ChromeOS, אלא בתוך תצוגת אינטרנט שמארח ספק הזהויות. ל-ChromeOS יש גישה ל-HTML, אבל אין דרך פשוטה וקנונית לקבל את הסיסמה כי לא ברור אילו שדות טופס מכילים את הנתונים.
יש שתי דרכים לקבל את הסיסמה של משתמש כשמשתמשים ב-SAML: ממשק ה-API להעברת פרטי כניסה וגירוד סיסמאות.
Chrome Credentials Passing API
Google מספקת Credentials Passing API שספקי זהויות יכולים להטמיע בדפי SAML, ב-JavaScript, כדי להעביר את הנתונים הנדרשים ל-ChromeOS. ממשק ה-API הזה משמש לאימות של Google, אבל כל ספק זהויות של SAML יכול להשתמש בו.
גירוד סיסמאות
ספק זהויות ב-SAML עשוי להשתמש בגירוד סיסמאות אם הוא לא תומך ב-Credentials Passing API.
בשיטה הזו:
- מסך האימות מחדיר סקריפט תוכן לתצוגת האינטרנט שמארחת את תהליך הכניסה.
- סקריפט התוכן מזהה שדות קלט HTML מסוג סיסמה ומעתיק את התוכן שלהם למערך. המערך מתעדכן בכל פעם שמשתנה התוכן של שדה סיסמה.
- הסיסמאות שנאספו נשלחות לדף ברקע שבו הן מצטברות. כך אפשר לתעד את הסיסמה גם אם תהליך הכניסה כולל כמה הפניות אוטומטיות לדפי HTML שונים.
בסוף תהליך ההתחברות, מערך הסיסמאות שחולצו מאוחזר מדף הרקע. יכולים להיות שלושה מקרים: לא נאספה סיסמה, נאספה סיסמה אחת בדיוק או שנאספו יותר מסיסמה אחת.
לא נאספה סיסמה
סקריפט התוכן לא מצליח לאתר את הסיסמה בדפי ה-HTML שמוצגים על ידי ספק הזהויות. יכול להיות שספק הזהויות לא משתמש בסיסמאות רגילות.
בתרחיש הזה, מערכת ChromeOS תבקש מהמשתמש לבחור סיסמה ידנית למכשיר. אם הסיסמה לא קיימת (למשל, אימות באמצעות כרטיסים חכמים, NFC או ביומטריה), תהליך האימות ב-ChromeOS עשוי להמשיך ללא הסיסמה.
בוצעה גריפה של סיסמה אחת בדיוק
סקריפט התוכן מזהה סיסמה אחת בלבד. ברוב המקרים, זו הסיסמה של המשתמש שמשמשת לאימות.
בתרחיש הזה, סביר להניח שגרדנו את הסיסמה של המשתמש בצורה נכונה. מערכת ChromeOS תשתמש בסיסמה שחולצה כסיסמת המשתמש כדי להמשיך את תהליך האימות.
יותר מסיסמה אחת נסרקה
סקריפט התוכן מזהה כמה סיסמאות. זה יכול לקרות בנסיבות שבהן ספק זהויות דורש ממשתמש להזין סיסמה קבועה וסיסמה חד-פעמית בטופס הכניסה.
בתרחיש הזה, סביר להניח שביצענו גירוד של הסיסמה בפועל של המשתמש ושל כמה שדות סיסמה נוספים שלא מעניינים את ChromeOS. כדי לקבוע איזו סיסמה נכונה, מערכת ChromeOS תבקש מהמשתמש להזין את הסיסמה שוב בהנחיה נוספת להזנת סיסמה.
אם הסיסמה שהוזנה תואמת לאחת הסיסמאות שנאספו, הסיסמה בפועל של המשתמש זוהתה ותהליך האימות יימשך. אם אין התאמה, המשתמש יתבקש להזין שוב את הסיסמה. אחרי שני ניסיונות כושלים, הכניסה נכשלת ומוצגת הודעת שגיאה.
רישום בארגון
כדי להירשם ל-Enterprise, צריך את כתובת האימייל של המשתמש שנרשם כדי לשייך את המכשיר לדומיין הנכון. האימייל נשלח משרת ניהול המכשירים (DM) אל Chrome בשדה שם המשתמש של הודעת PolicyData במהלך אחזור מדיניות המכשיר. אין צורך לקבוע את הסיסמה של המשתמש.