הרשאה

אפליקציות מאשרות קריאות לממשק ה-API של הלקוח להרשמה דרך הארגון באמצעות OAuth. במסמך הזה מוסבר על ההרשאה של ה-API לספקים של ניהול ניידות ארגונית (EMM) ולמפתחי IT בארגונים. אחרי שתקראו את המסמך הזה, תוכלו לדעת איך לאשר בקשות API באפליקציה ולהסביר את דרישות החשבון למשתמשי האפליקציה.

מדריך למתחילים בנושא הרשאות

  • כדי להגדיר פרויקט ב-Google Cloud Platform באמצעות ה-API להרשמה דרך הארגון וסודות לקוח ב-OAuth, צריך להפעיל את האשף הזה.
  • יוצרים את הקוד לדוגמה למתחילים ל-Java, NET. או Python. שימוש בספריות הלקוח של ה-API של Google כדי לתמוך בשפות אחרות.

סקירה כללית

הקשר בין המכשיר למשאב הלקוח

  1. מנהל IT אחד או יותר הם משתמשים בחשבון לקוח שנרשם דרך הארגון.
  2. מנהלי IT משתמשים בחשבון Google כדי לאמת את עצמם.
  3. בקשות API מעבירות אסימון OAuth2 כדי לאשר בקשות API מטעם מנהל IT.

חשבונות לקוח

ההגדרות, המכשירים והמשתמשים (אדמינים ב-IT) של הארגון שייכים לחשבון לקוח. חשבון לקוח דומה לקבוצה ולא משתמש פרטי. המפיץ מגדיר את הלקוח בפעם הראשונה שהארגון רוכש מכשירים להרשמה דרך הארגון. מנהלי IT מנהלים משתמשים אחרים בארגון שלהם באמצעות פורטל ההרשמה דרך הארגון.

ה-API משתמש במספרי לקוחות מספריים כדי לזהות חשבונות. את מספר הלקוח מעבירים כחלק מנתיב כתובת ה-URL כשמפעילים שיטות API. האפליקציה צריכה לקבל את מספר הלקוח של המשתמש לפני הפעלת שיטות API.

הדוגמה הבאה מראה איך להשיג את חשבונות הלקוח עבור המשתמש שמאשר את הקריאה ל-API:

Java

AndroidProvisioningPartner.Customers.List accountRequest = service.customers().list();
accountRequest.setPageSize(100);
CustomerListCustomersResponse accountResponse = accountRequest.execute();

List<Company> customers = accountResponse.getCustomers();
if (customers == null || customers.isEmpty()) {
    // No accounts found for the user. Confirm the Google Account
    // that authorizes the request can access the zero-touch portal.
    System.out.println("No zero-touch enrollment account found.");
} else {
    // Print the customers in this page.
    for (Company customer : customers) {
        System.out.format("%s\tcustomers/%d\n",
              customer.getCompanyName(), customer.getCompanyId());
    }
}

‎.NET

CustomersResource.ListRequest accountRequest = service.Customers.List();
accountRequest.PageSize = 100;
CustomerListCustomersResponse accountResponse = accountRequest.Execute();
IList<Company> customers = accountResponse.Customers ?? new List<Company>();
if (customers.Count == 0)
{
    // No accounts found for the user. Confirm the Google Account
    // that authorizes the request can access the zero-touch portal.
    Console.WriteLine("No zero-touch enrollment account found.");
}
foreach (Company customer in customers)
{
    Console.WriteLine("{0}\tcustomers/{1}",
                      customer.CompanyName,
                      customer.CompanyId);
}

Python

response = service.customers().list(pageSize=100).execute()
if 'customers' not in response:
  # No accounts found for the user. Confirm the Google Account
  # that authorizes the request can access the zero-touch portal.
  print('No zero-touch enrollment account found.')
  response['customers'] = []

for customer in response['customers']:
  print('{0}\tcustomers/{1}'.format(
      customer['companyName'], customer['companyId']))

באפליקציה שלכם תצטרכו לעבור אל דפי התוצאות של החשבונות, כי בדוגמה שלמעלה מדפיסים רק 100 החשבונות הראשונים. במאמר תוצאות לפי דפים מוסבר איך עושים זאת.

לארגון יש בדרך כלל חשבון לקוח אחד, אבל ארגונים גדולים עשויים להשתמש בחשבונות לקוח נפרדים לכל מחלקה. מנהלי IT יכולים להיות חברים בחשבונות לקוח שונים, ולכן האפליקציה צריכה לעזור למשתמשים למצוא חשבונות לקוח חדשים ולהשתמש בהם. באפליקציה, מוסיפים תוויות לכל חשבון לקוח באמצעות הערך companyName.

משתמשים

מנהלי IT מאשרים את בקשות ה-API שהאפליקציה שולחת בשמם. כדי לאשר בקשות API, המשתמשים באפליקציה צריכים לבצע את הפעולות הבאות:

  1. משייכים חשבון Google לכתובת האימייל שלהם.
  2. להצטרף לחשבון לקוח באמצעות אותה כתובת אימייל.
  3. מאשרים את התנאים וההגבלות (ToS) של ההרשמה דרך הארגון.

כדי לעזור למשתמשי האפליקציה להגדיר את האפליקציה, השתמשו שוב בהנחיות שלנו למנהלי IT בקטע תחילת העבודה ושיוך חשבון Google במסמכים שלכם.

ניהול המשתמשים

אדמינים ב-IT מנהלים את המשתמשים בחשבונות של הלקוחות בפורטל ההרשמה דרך הארגון. למשתמשים בחשבון לקוח יש תפקיד של בעלים או אדמין. לשני התפקידים יש גישה זהה ל-API של הלקוח, אבל משתמש עם התפקיד בעלים יכול לנהל משתמשים אחרים.

אישור התנאים וההגבלות

כדי שהמשתמשים של האפליקציה יוכלו לאשר קריאות ל-API, הם צריכים לאשר את התנאים וההגבלות האחרונים. המצב הזה קורה כשאדמינים ב-IT משתמשים בפעם הראשונה בהרשמה דרך הארגון או כשאנחנו מעדכנים את התנאים וההגבלות. כשמשתמש לא מאשר את התנאים וההגבלות העדכניים, ה-API מחזיר קוד סטטוס 403 Forbidden של HTTP וגוף התגובה מכיל TosError.

בפורטל, המשתמשים יתבקשו לאשר את התנאים וההגבלות העדכניים כשהם נכנסים לחשבון. כדי לקבל גישה לגישות המומלצות לאפליקציה שלך, קראו את התנאים וההגבלות של הכינוי במדריך לשילוב EMM.

הוספת הרשאה לאפליקציה

כל בקשה שהאפליקציה שולחת ל-API של הלקוח צריכה לכלול אסימון הרשאה. אסימון ההרשאה גם מזהה את האפליקציה שלכם ב-Google. מאחר ש-API של הלקוח ניגש לנתוני המשתמשים, ההרשאה צריכה להגיע מהבעלים של הנתונים. האפליקציה שלך מקצה הרשאות API למנהלי IT באמצעות פרוטוקול OAuth 2.0.

הוראות

אנחנו מספקים מדריכים למתחילים לאפליקציות Java, .NET ו-Python. אם אתם משתמשים בשפה אחרת, בצעו את שני השלבים הבאים כדי להגדיר הרשאה לאפליקציה.

למידע נוסף על הרשאה, קראו את המאמר שימוש ב-OAuth 2.0 לגישה ל-Google API.

היקפי הרשאות

משתמשים בהיקף ההרשאות של ה-API https://www.googleapis.com/auth/androidworkzerotouchemm באפליקציה כדי לבקש אסימון גישה מסוג OAuth 2.0.

פרמטר של היקף קובע את קבוצת המשאבים והפעולות שאסימון הגישה מאפשר לקרוא אליהם. אסימוני הגישה תקפים רק לקבוצת הפעולות והמשאבים שמתוארים במסגרת בקשת האסימון. ה-API כולל את כל השיטות והמשאבים שכלולים בהיקף ההרשמה דרך הארגון שמופיע למעלה.

דוגמה להיקף ההרשמה דרך הארגון שנעשה בו שימוש בספריית הלקוח של Google API, תוכלו להיעזר במדריכים למתחילים של Java, .NET ו-Python. למידע נוסף על השימוש בהיקפים של Google API, קראו את המאמר שימוש ב-OAuth 2.0 לגישה ל-Google APIs.

שיטות מומלצות לשימוש במפתחות API

בזמן השימוש במפתחות API באפליקציות שלכם, חשוב לשמור על האבטחה שלהם. חשיפת פרטי הכניסה באופן גלוי לכולם עלולה לגרום לפגיעה בחשבון, מה שיכול להוביל לחיובים לא צפויים בחשבון. כדי לשמור על האבטחה של מפתחות ה-API, כדאי לפעול לפי השיטות המומלצות הבאות:

לא להטמיע מפתחות API ישירות בקוד
מפתחות API שמוטמעים בקוד עלולים להיחשף בטעות באופן ציבורי לכולם, למשל אם שוכחים להסיר את המפתחות מקוד ששיתפתם. במקום להטמיע את מפתחות ה-API באפליקציות, כדאי לאחסן אותם במשתני סביבה או בקבצים מחוץ לעץ המקור של האפליקציה.
לא לאחסן מפתחות API בקבצים בתוך עץ המקור של האפליקציה
אם שמרת מפתחות API בקבצים, עליך להשאיר אותם מחוץ לעץ המקור של האפליקציה, כדי להבטיח שהמפתחות לא יגיעו למערכת הבקרה של קוד המקור. חשוב מאוד לעשות זאת אם משתמשים במערכת ציבורית לניהול קוד מקור, כמו GitHub.
אפשר להגביל את השימוש במפתחות ה-API לשימוש רק לכתובות ה-IP, לכתובות ה-URL של הגורמים המפנים ולאפליקציות לנייד שזקוקות להם
כשמגבילים את כתובות ה-IP, את כתובות ה-URL של הגורמים המפנים ואת האפליקציות לנייד שיכולות להשתמש בכל מפתח, אפשר לצמצם את ההשפעה של מפתח API שנחשף. אפשר לציין את המארחים והאפליקציות שיכולים להשתמש בכל מפתח מ-Google API Console באמצעות פתיחת הדף Credentials (פרטי כניסה) ויצירת מפתח API חדש עם ההגדרות הרצויות, או עריכת ההגדרות של מפתח API.
למחוק מפתחות API שכבר לא נחוצים
כדי לצמצם את החשיפה להתקפות, כדאי למחוק מפתחות API שכבר אין לך צורך בהם.
מדי פעם ליצור מחדש את מפתחות ה-API
אפשר ליצור מחדש מפתחות API דרך Google API Console: פותחים את הדף Credentials, בוחרים מפתח API ולוחצים על Regenerate key לכל מפתח. לאחר מכן צריך לעדכן את האפליקציות כך שישתמשו במפתחות החדשים שנוצרו. המפתחות הישנים ימשיכו לפעול למשך 24 שעות לאחר יצירת המפתחות החלופיים.
צריך לבדוק את הקוד לפני שמפיצים אותו באופן ציבורי
לפני שמפרסמים את הקוד כגלוי לכולם, חשוב לוודא שהקוד לא מכיל מפתחות API או מידע פרטי אחר.