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. |
| תעודה המזהה | כן | באפליקציות אינטרנט, מזינים את מזהה הלקוח ב-OAuth שהונפק לאפליקציה. באפליקציות ל-Android ול-iOS, מזינים את מזהה הלקוח ב-OAuth או את מזהה החבילה שהאפליקציה משתמשת בו ב-Google Play או ב-Apple App Store. |
| יחידה ארגונית | כן | למילוי על ידי הלקוח. מזינים קו נטוי (/) כדי להחיל את הגדרת הגישה לאפליקציה על כל הדומיין. כדי להחיל הגדרות גישה על יחידות ארגוניות ספציפיות, מוסיפים שורה לגיליון האלקטרוני לכל יחידה ארגונית, וחוזרים על שם האפליקציה, הסוג והמזהה. (לדוגמה, '/org_unit_1/sub_unit_1'). |
| גישה | כן | אחת מהאפשרויות מהימנה, חסומה או מוגבלת. |
שגיאות OAuth
הוספנו שתי הודעות שגיאה חדשות שמוצגות עם אמצעי הבקרה החדשים לאדמינים.
- Error 400: access_not_configured – מתקבל כשחיבור OAuth נדחה כי האפליקציה לא הוגדרה.
- שגיאה 400: admin_policy_enforced – מתקבלת כשחיבור OAuth נדחה כי האדמין חסם את האפליקציה.
משתמשים שסווגו כמתחת לגיל 18
אדמינים יכולים לנהל את הגישה של משתמשים שסווגו כמתחת לגיל 18 לאפליקציות של צד שלישי שלא הוגדרו. אם משתמש נתקל בשגיאה "הגישה חסומה: האפליקציה [שם האפליקציה] צריכה להיבדק על ידי האדמין של המוסד שלך", הוא צריך לבקש גישה מתוך הודעת השגיאה. כך האדמין יוכל לבדוק את האפליקציה של הצד השלישי. אדמינים יכולים להחליט אם לאשר או לחסום אפליקציות של צד שלישי.