הקצאת חשבונות משתמש

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

בסביבה ארגונית של Android, פרטי החשבון נשמרים בשלוש מערכות שונות:

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

---

משאב Users מייצג חשבון שמשויך לארגון. החשבון יכול להיות ספציפי למכשיר מסוים, או להיות משויך לאדם שיש לו כמה מכשירים (טלפון נייד, טאבלט וכו') והוא משתמש בחשבון בכל המכשירים האלה. החשבון יכול לספק גישה ל-Google Play המנוהל בלבד, או לשירותים אחרים של Google, בהתאם לאופן שבו מגדירים את הארגון של הלקוח:

• קבוצות חשבונות Google Play לארגונים מספקות לארגונים דרך שקיפות ליצירת חשבונות משתמשים או חשבונות מכשירים באופן אוטומטי דרך ספק הפתרון של ניהול ניידות הארגון (EMM). החשבונות האלה מספקים גישה ל-Google Play לארגונים בלבד.

• חשבונות Google הם חשבונות קיימים שמנוהלים על ידי Google, ויש צורך בסנכרון שלהם עם מקורות של חשבונות Google.

טבלה 1: שדות ושיטות של Users API

	חשבונות Google Play מנוהלים	חשבונות מנוהלים של Google
שדה
id [מזהה]
סיווג
accountIdentifier	מזהה ייחודי שאתם יוצרים וממפים למזהה (userId) שמוחזר מ-Google Play. אין להשתמש בפרטים אישיים מזהים (PII).	לא מוגדר.
accountType	deviceAccount, ‏ userAccount	userAccount
displayName	השם שמוצג בפריטים בממשק המשתמש, למשל ב-Google Play. אין להשתמש בפרטים אישיים מזהים.	לא מוגדר.
managementType	emmManaged	googleManaged, ‏ emmManaged
primaryEmail	לא מוגדר.	השדה הזה הוא המפתח הראשי שדרכו מנהלים את הסנכרון מחשבונות דומיין בניהול Google לחשבונות משתמשים במערכת.
Methods
delete
generateAuthenticationToken
generateToken
get
getAvailableProductSet
insert
list
revokeToken
setAvailableProductSet
עדכון

---

חשבונות Google Play מנוהלים

יש שני סוגים של חשבונות Google Play מנוהלים:

חשבון משתמש

מספקת למשתמש יחיד גישה ל-Google Play המנוהל מכל המכשירים שלו. אתם צריכים להקצות חשבונות משתמשים למשתמשים שלכם – אין להם את פרטי הכניסה להוספת חשבונות Google Play מנוהלים בעצמם.

כדי ליצור חשבון משתמש, קוראים לפונקציה Users.insert. מגדירים את סוג החשבון כ-userType ומגדירים accountIdentifier שמפנה באופן ייחודי למשתמש בארגון.

שיטה מומלצת: אל תשתמשו באותו חשבון ביותר מ-10 מכשירי

חשבון במכשיר

מספק גישה ל-Google Play המנוהל ממכשיר אחד. אם הונפק אסימון אימות לחשבון מכשיר, בקשה חדשה לאסימון אימות לאותו חשבון מכשיר תשבית את האסימון הקודם. לכל מכשיר צריכים להיות רישיונות נפרדים משלו לאפליקציות.

כדי ליצור חשבון מכשיר, קוראים ל-Users.insert ומגדירים את סוג החשבון בתור deviceType.

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

דרישות למסופים ולשרתים של EMM

חשבונות Google Play מנוהלים נוצרים על פי דרישה, באופן פרוגרמטי, באמצעות ממשקי ה-API של Google Play EMM וממשקי ה-API של Android framework בכל הרכיבים של פתרון ה-EMM (מסוף EMM, שרת EMM ו-DPC). הרכיבים האלה פועלים יחד במהלך זמן הריצה כדי ליצור חשבון משתמש ולהקצות את פרופיל העבודה במכשיר היעד.

השרת או מסוף ה-EMM צריכים:

• צריך לספק מנגנון ליצירת מזהים אנונימיים ייחודיים של חשבונות (השדה accountIdentifier) לשימוש בקריאה ל-Users.insert. לדוגמה, אפשר להשתמש בערך פנימי כלשהו של המשתמש ('sanjeev237389') או במספר תג נכס סתום ('asset#44448'). מומלץ לא להשתמש בפרטי מזהה אישי (PII) למזהה החשבון.

• שומרים את המיפוי בין userId (החזרה מהקריאה ל-insert) לבין accountIdentifier שבחרתם.

הערה: כשיוצרים חשבון Google Play מנוהל, צריך להשתמש במזהה אנונימי שלא חושף את הזהות האמיתית של המשתמש ל-Google. לדוגמה:

• מגדירים את accountIdentifier למזהה פנימי קיים או למיפוי חדש שיוצרים. אל תשתמשו בשם או בכתובת האימייל של המשתמש.
• משאירים את נכס displayName ללא הגדרה, או מגדירים לו שם כללי לכם או לארגון, למשל 'ACME, Inc.‎'

הדרישות ל-DPC מפורטות במאמר פיתוח של בקר מדיניות מכשיר.

יצירת חשבון משתמש מנוהל ב-Google Play

1. משתמש נכנס ל-DPC באמצעות פרטי כניסה של הארגון (בדרך כלל).
2. ה-DPC מבקש פרטים על המשתמש מהשרת או מהמסוף של ה-EMM. בהנחה שהמשתמש לא מוכר למערכת:
   1. שולחים בקשה לחשבון Google Play מנוהל חדש באמצעות קריאה ל-Users.insert עם ערכים חדשים של accountIdentifier,‏ displayName ו-accountType.
      • המערכת צריכה ליצור את accountIdentifier. מזהה החשבון חייב להיות ערך ייחודי במערכת. אין להשתמש בפרטי מידע אישי מזהים (PII) למזהה החשבון.
      • הערך displayName מוצג במנגנון החלפת החשבון בחנות Google Play, וצריך להיות לו משמעות כלשהי למשתמש (אבל לא פרטים אישיים מזהים של המשתמש). לדוגמה, השם יכול לכלול את שם הארגון או שם כללי שקשור ל-EMM.
      • מגדירים את accountType לערך userAccount או deviceAccount. אפשר להשתמש ב-userAccount בכמה מכשירים, אבל deviceAccount ספציפי למכשיר אחד. הערך שצוין בשדה accountType יכול להיות deviceType או userType.
      • מגדירים את managementType להיות emmManaged.
   2. Google Play מעבדת את הבקשה, יוצרת את החשבון ומחזירה userId.
   3. שומרים את המיפוי בין accountIdentifier לבין userId במאגר הנתונים.
   4. מתקשרים למספר Users.generateAuthenticationToken באמצעות הלחצנים userId ו-enterpriseId. Google Play מחזירה אסימון אימות שאפשר להשתמש בו פעם אחת, וצריך להשתמש בו תוך כמה דקות.
   5. מעבירים את אסימון האימות ל-DPC באופן מאובטח.
3. ה-DPC מקצה את פרופיל העבודה ומוסיף את החשבון לפרופיל העבודה או למכשיר.
4. המשתמש יכול לגשת ל-Google Play המנוהל בפרופיל העבודה או במכשיר.

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

חשבונות אדמין

כשאדמין יוצר ארגון עם חשבונות Google Play מנוהלים, חשבון Google שבו הוא משתמש לא יכול להיות חשבון G Suite. החשבון שבו הם משתמשים הופך לחשבון הבעלים של הארגון, והבעלים יכול להוסיף עוד בעלים ואדמינים במסוף Google Play המנוהל.

הן הפונקציה Enterprises.get והן הפונקציה Enterprises.completeSignup מחזירות רשימה של כתובות אימייל של אדמינים שמשויכות לארגון (ארגונים עם חשבונות Google Play מנוהלים בלבד).

ניהול מחזורי החיים של חשבונות

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

יוצרים את החשבונות במהלך הקצאת המכשיר, תהליך שכולל את אפליקציית ה-DPC ואת מסוף ה-EMM. להוראות, ראו השיטה 'חשבונות Google Play מנוהלים'.

הערה חשובה בנושא פרטיות: כשיוצרים חשבון Google Play מנוהל, צריך להשתמש במזהה אנונימי שלא חושף ל-Google את הזהות בפועל של המשתמש. לדוגמה:

• מגדירים את accountIdentifier למזהה פנימי קיים או למיפוי חדש שיוצרים. אל תשתמשו בשם או בכתובת האימייל של המשתמש.
• משאירים את נכס displayName ללא הגדרה, או מגדירים לו שם כללי לכם או לארגון, למשל 'ACME, Inc.‎'

כדי לשנות את פרטי החשבון, צריך להפעיל את השיטה Users.update.

כדי למחוק חשבון, צריך להפעיל את הפונקציה Users.delete.

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

תפוגת התוקף של החשבון

לפעמים פג התוקף של חשבונות או של האסימונים שלהם, ויכולות להיות לכך כמה סיבות:

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

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

כדי לחדש את האסימון בצורה תקינה, צריך:

1. צריך להתקשר למספר users.generateAuthenticationToken כדי לבקש אסימון אימות חדש לחשבון.
2. אם הקריאה תתבצע בהצלחה, תוכלו להסיר את החשבון הקיים ולהוסיף את החשבון החדש באמצעות ספריית התמיכה של DPC.
3. אם הקריאה לא תצליח, מסירים את החשבון מהמכשיר ויוצרים משתמש חדש באמצעות users.insert, יוצרים אסימון אימות ומוסיפים את החשבון למכשיר.

Google Play Services בגרסה 9.0.00 תודיע ל-DPC שהתוקף של החשבון פג באמצעות פעולת השידור:

1. כשחשבון Google Play המנוהל לא תקף במכשיר, ה-DPC מקבל שידור עם הפעולה הבאה:

   com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED

   ה-Intent של השידור מכיל את ה-extra Parcelable בשם account, שהוא האובייקט Account של החשבון שהתוקף שלו בוטל.

2. ה-DPC בודק את Account#name עם שרת ה-EMM כדי לזהות את החשבון שהתוקף שלו בוטל.

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

---

חשבונות Google

בארגונים שמשתמשים בחשבונות Google, חשבונות המשתמשים בפתרון של ה-EMM משקפים חשבונות משתמשים קיימים המשויכים לשירות אחר של Google (לדוגמה, G Suite). החשבונות האלה הם מסוג googleManaged (טבלה 1) כי שירותי הקצה העורפי של Google הם המקור ליצירת החשבון ולמידע עליו.

בתור מערכת ניהול משתמשים בארגון, אתם יכולים לספק במסוף מנגנונים שיעזרו לכם ליצור חשבונות משתמשים במערכת ולסנכרן אותם באופן שוטף עם מקורות החשבונות שלהם בדומיין Google. לשם כך, תוכלו להשתמש בכלים כמו Google Cloud Directory Sync‏ (GCDS) ו-Google Admin SDK Directory API. תוכלו לקרוא כאן סקירה כללית על גישות שונות. במודל הזהויות של דומיינים בניהול Google, חשבון המשתמש צריך להתקיים בהקשר של הפתרון (מסוף EMM, שרת EMM, אולי במאגר נתונים) כדי שאפשר יהיה להקצות אותו לאחד מהמכשירים של המשתמש בהקשר של פרופיל עבודה.

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

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

סנכרון של חשבונות לקוח

בפריסה של חשבונות Google, הארגון יכול להשתמש בכלי GCDS כדי לסנכרן את הנתונים בדומיין G Suite עם הנתונים בספריית ה-LDAP. לחלופין, אפשר להשתמש ב-GCDS כדי לעשות זאת בשם הארגון, אם יש לכם גישה לארגון.

הכלי GCDS קורא ל-Google Directory API ומסנכרן שמות משתמשים, אבל לא סיסמאות.

אם הארגון משתמש ב-Microsoft Active Directory ורוצים שהסיסמאות של המשתמשים ב-G Suite יסתנכרנו עם הסיסמאות שלהם ב-Active Directory, תוכלו להשתמש בכלי G Suite Password Sync (GSPS) עם GCDS.

להוראות לאדמינים בנושא GCDS, אפשר לעיין במאמר הכנת הדומיין של G Suite לסנכרון.

Google Directory API

בפריסה של חשבונות Google, אפשר להשתמש ב-Google Directory API כדי לסנכרן ספריות פעילות, סיסמאות או את שניהם:

• שימוש ב-Directory API לסנכרון של ספריות בלבד אם יש לכם גישה לקריאה בלבד לדומיין Google המנוהל של הארגון, תוכלו להשתמש ב-Google Directory API כדי לקבל מ-Google פרטים של חשבונות Google, כמו שמות משתמשים (אבל לא סיסמאות). מכיוון שאין לכם אפשרות לכתוב נתונים בחשבונות Google של המשתמשים, הארגון אחראי באופן מלא למחזור החיים של החשבונות.

  תרחיש 1 ותרחישי אימות SSO מבוססי-SAML מתארים את המצב הזה בצורה מקיפה יותר.

  מידע נוסף על השימוש ב-Directory API בדרך הזו זמין במאמר אחזור כל המשתמשים בחשבון במסמכי התיעוד של Directory API.

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

  בתרחיש 2 מתואר המצב הזה בצורה מפורטת יותר.

  מידע נוסף על השימוש ב-Directory API לניהול פרטי חשבונות משתמשים זמין במדריך למפתחים בנושא Directory API: User Accounts.

תרחישים של חשבונות Google

בהמשך מפורטים כמה תרחישים אופייניים של הקצאת זהויות בחשבונות Google.

תרחיש 1: הלקוח אחראי למחזור החיים של החשבון

בתרחיש הזה, הלקוח יוצר חשבונות Google למשתמשיו ומנהל אותם.

אתם מקבלים את פרטי חשבון המשתמש מהספרייה של LDAP בארגון, ומתאימים אותם לנתונים של חשבון Google שאתם מקבלים מ-Google דרך Directory API של Google.

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

במקרה כזה:

• יש לכם הרשאת קריאה בלבד לחשבונות Google.
• מסד הנתונים מקבל שמות של חשבונות Google, אבל לא שמות משתמשים או סיסמאות של LDAP.
• אתם משתמשים ב-Google Directory API כדי לקבל פרטי חשבון בסיסיים של המשתמשים של הלקוח. (המידע שזמין לכם הוא המידע שלא ניתן לכתוב בו שחוזר מהבקשה Users.get). אתם משתמשים במידע הזה כדי לוודא שחשבונות Google של המשתמשים קיימים, וכך המשתמשים יכולים לבצע אימות במכשירים שלהם.
• הלקוח משתמש בכלי GCDS כדי לבצע סנכרון חד-כיווני כדי לאכלס את חשבונות Google של המשתמשים. (סביר להניח שהארגון משתמש ב-GCDS גם לסנכרון שוטף משלו אחרי השלמת הקצאת הזהויות). לחלופין, הארגון יכול להשתמש בכלי GSPS כדי לסנכרן לא רק שמות משתמשים, אלא גם סיסמאות.

תרחיש 2: ה-EMM אחראי למחזור החיים של החשבון

בתרחיש הזה, אתם מטפלים בתהליך יצירת חשבונות Google בשם הלקוח, ואתם אחראים למחזור החיים של חשבונות המשתמשים.

לדוגמה, כשפרטי המשתמש משתנים בספריית ה-LDAP של הארגון, אתם אחראים לעדכן את חשבון Google של המשתמש. לא נעשה שימוש ב-GCDS בתרחיש הזה.

במקרה כזה:

• יש לכם הרשאת קריאה וכתיבה לחשבונות Google.
• מסד הנתונים מקבל שמות של חשבונות Google ושמות משתמשים ב-LDAP (ואם רוצים, גם גיבוב של סיסמאות).
• אתם משתמשים ב-Google Directory API בשם הלקוח כדי לקרוא ולכתוב את פרטי החשבון של המשתמשים בארגון. (המידע שזמין לכם הוא המידע שלא ניתן לכתוב בו שחוזר מהבקשה Users.get). אתם משתמשים במידע הזה כדי לוודא שחשבונות Google של המשתמשים קיימים, וכך המשתמשים יכולים לבצע אימות במכשירים שלהם.
• לא נעשה שימוש בכלי GCDS.

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

תרחישים של אימות SSO מבוסס-SAML

בפריסה של חשבונות Google, יכול להיות שאתם או הלקוח שלכם תשתמשו בשפת Markup של טענת נכוֹנוּת (SAML) עם ספק זהויות (IdP) כדי לאמת את חשבון Google שמשויך לכל משתמש. אתם משתמשים בשמות של חשבונות Google כאימות לכך שחשבונות Google של המשתמשים קיימים, וזה נדרש לאימות המשתמשים כשהם נכנסים למכשירים שלהם. לדוגמה, אפשר להשתמש ב-SAML בתרחיש 2. פרטים על הגדרת האפשרות הזו מופיעים במאמר הגדרת כניסה יחידה (SSO) לחשבונות G Suite.

הפעלת חשבונות במכשירים

כדי להפיץ אפליקציות למכשיר של משתמש דרך Google Play לארגונים, המשתמש צריך להיכנס לחשבון במכשיר במהלך הקצאת המכשיר:

• בהקצאת מכשיר מנוהלת לחשבונות Google Play, ה-DPC מנחה את המשתמש להיכנס באמצעות פרטי כניסה שמקובלים במסוף ה-EMM, בדרך כלל פרטי כניסה לחשבון אימייל עסקי.
• בפריסה של חשבונות Google, ה-DPC מנחה את המשתמש להזין את פרטי הכניסה לחשבון Google שלו. בדרך כלל, פרטי הכניסה האלה תואמים לאלה שבהם המשתמשים נכנסים לדומיין העסקי שלהם כשהם מסונכרנים עם GCDS או GSPS, או כשארגון משתמש ב-IdP לאימות. הפעולה הזו מפעילה את חשבון Google של המשתמש, יוצרת מזהה מכשיר ייחודי ומקשרת בין הזהות של חשבון Google של המשתמש לבין מזהה המכשיר שלו.