Google הציגה הגדרות של אמצעים לבקרת גישה לאפליקציות כדי להקל על אדמינים של Google Workspace for Education לשלוט בגישה של אפליקציות צד שלישי לנתונים בחשבון Google של הארגון שלהם כשמשתמשים נכנסים באמצעות החשבונות שלהם ב-Google Workspace for Education. מפתחי אפליקציות של צד שלישי לא נדרשים לבצע פעולות כלשהן, אבל בהמשך מפורטות כמה שיטות מומלצות שמפתחים אחרים מצאו כמועילות.
שימוש ב-OAuth מצטבר
אתם יכולים להשתמש בהרשאה מצטברת כדי לבקש בהתחלה רק את היקפי ההרשאות שנדרשים להפעלת האפליקציה, ואז לבקש היקפי הרשאות נוספים כשנדרשות הרשאות חדשות. ההקשר של האפליקציה מזהה את הסיבה לבקשה למשתמש.
במהלך הכניסה לחשבון, האפליקציה מבקשת הרשאות בסיסיות כמו הרשאת הכניסה לפרופיל והרשאות ראשוניות אחרות שהאפליקציה צריכה כדי לפעול. בהמשך, כשהמשתמש ירצה לבצע פעולה שמחייבת היקפי הרשאות נוספים, האפליקציה תבקש את היקפי ההרשאות הנוספים האלה והמשתמש יאשר רק את היקפי ההרשאות החדשים במסך ההסכמה.
כשמפתחים תוסף ל-Google Classroom, צריך לפעול בהתאם להנחיות של Google Workspace Marketplace ולספק רשימה מלאה של היקפי ההרשאות בפרוטוקול OAuth שהאפליקציה דורשת. ההסכמה הזו נדרשת כדי שמנהל יוכל להבין לאילו היקפי הרשאות המשתמש בדומיין מתבקש להסכים.
לוודא שכל האפליקציות מאומתות באמצעות OAuth
כל האפליקציות שיש להן גישה ל-Google APIs צריכות לאמת שהן מייצגות בצורה מדויקת את הזהות והכוונה שלהן, כפי שמפורט במדיניות נתוני המשתמש של שירותי Google API. אם אתם מנהלים כמה אפליקציות שמשתמשות ב-Google APIs, ודאו שכל אפליקציה אומתה. יכול להיות שהאדמינים יראו את כל מזהי הלקוחות ב-OAuth שמשויכים למותג המאומת שלכם. כדי לעזור לאדמינים להימנע מהגדרת מזהי לקוחות שגויים ב-OAuth, מומלץ להשתמש בפרויקטים נפרדים ב-Google Cloud לבדיקות ולייצור ולמחוק את כל מזהי הלקוחות ב-OAuth שלא נמצאים בשימוש.
אימות OAuth API הוא תהליך שבו משתמשים ב-Google Cloud Platform כדי לוודא שאפליקציות שמבקשות היקפים רגישים או מוגבלים הן מאובטחות ועומדות בדרישות. תהליך האימות עוזר להגן על משתמשי Google Cloud ועל הנתונים שלהם מפני גישה לא מורשית.
אפליקציות שמבקשות היקפי הרשאות רגישים או מוגבלים חייבות לעמוד בדרישות המדיניות של Google בנושא נתוני משתמשים בשירותי API. המדיניות הזו מחייבת את האפליקציות להגן על נתוני המשתמשים ולהשתמש בנתונים רק למטרות שהמשתמש אישר. יכול להיות שיהיה צורך גם לבצע הערכת אבטחה עצמאית לאפליקציות כדי לוודא שהן עומדות בדרישות האבטחה של Google Cloud.
שימו לב: תהליך האימות של OAuth API יכול להימשך עד כמה שבועות. אחרי שהאפליקציה תאומת, תוכלו לבקש את ההיקפים הרגישים או המוגבלים שאתם צריכים.
פרטים נוספים מופיעים בשאלות הנפוצות בנושא אימות אפליקציות באמצעות OAuth API.
טיפול בכמה מזהי לקוחות ב-OAuth
יכול להיות שלפרויקט בענן ב-Google Cloud יש כמה מזהי לקוח OAuth, ולכן יכול להיות שאדמין הדומיין יידרש להגדיר את הגישה כמה פעמים.
איך מוודאים שמזהי הלקוחות ב-OAuth מדויקים
כדאי לבדוק עם צוות הפיתוח כדי להבין באילו מזהי לקוחות ב-OAuth נעשה שימוש לצורך שילוב עם Google OAuth. כדי לעזור לאדמינים להבין אילו מזהי לקוח OAuth צריך להגדיר, כדאי להשתמש בשני פרויקטים שונים ב-Google Cloud לבדיקות ולייצור. מוחקים מזהי לקוח שהוצאו משימוש או לא עדכניים מהפרויקטים שלכם בסביבת הייצור.
העלאת קובץ CSV
אם יש לכם כמה מזהי לקוח, מומלץ להשתמש באפשרות העלאה בכמות גדולה של קובצי CSV כדי לעזור לאדמינים להגדיר במהירות את כל האפליקציות.
השדות הם:
| שדה | חובה | הערות |
|---|---|---|
| שם האפליקציה | לא | מזינים את שם האפליקציה. שינויים שאתם מבצעים בשם האפליקציה בקובץ ה-CSV לא מתעדכנים במסוף Admin. |
| סוג | כן | אחת מהאפשרויות הבאות: אפליקציית אינטרנט, Android או iOS. |
| Id | כן | באפליקציות אינטרנט, מזינים את מזהה הלקוח ב-OAuth שהונפק לאפליקציה. באפליקציות ל-Android ול-iOS, מזינים את מזהה הלקוח ב-OAuth או את מזהה החבילה שהאפליקציה משתמשת בו ב-Google Play או ב-Apple App Store. |
| יחידה ארגונית | כן | למילוי על ידי הלקוח. מזינים קו נטוי (/) כדי להחיל את הגדרת הגישה לאפליקציה על כל הדומיין. כדי להחיל הגדרות גישה על יחידות ארגוניות ספציפיות, מוסיפים שורה לגיליון האלקטרוני לכל יחידה ארגונית, וחוזרים על שם האפליקציה, הסוג והמזהה. (לדוגמה, '/org_unit_1/sub_unit_1'). |
| גישה | כן | אחת מהאפשרויות הבאות: מהימנה, חסומה או מוגבלת. |
שגיאות OAuth
הוספנו שתי הודעות שגיאה חדשות שמוצגות עם אמצעי הבקרה החדשים לאדמינים.
- Error 400: access_not_configured – מתקבל כשחיבור OAuth נדחה כי האפליקציה לא הוגדרה.
- Error 400: admin_policy_enforced – מתקבלת כשחיבור OAuth נדחה כי האדמין חסם את האפליקציה.
משתמשים שסווגו כמתחת לגיל 18
אדמינים יכולים לנהל את הגישה של משתמשים מתחת לגיל 18 לאפליקציות של צד שלישי שלא הוגדרו. אם משתמש נתקל בשגיאה "הגישה חסומה: האפליקציה [שם האפליקציה] צריכה להיבדק על ידי האדמין של המוסד שלך", הוא צריך לבקש גישה מתוך הודעת השגיאה. כך האדמין יוכל לבדוק את האפליקציה של הצד השלישי. אדמינים יכולים להחליט אם לאשר או לחסום אפליקציות של צד שלישי.