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

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

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

• ספריית המשתמשים של הארגון היא המקור המוסמך למידע על המשתמשים.
• אתם (ספקי פתרונות 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, והוא צריך להיות בעל משמעות כלשהי עבור המשתמש (אבל לא פרטים אישיים מזהים (PII) על המשתמש). לדוגמה, השם יכול לכלול את שם הארגון או שם כללי שקשור ל-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 אחר, המכשיר לא מזוהה על ידי ה-EMM החדש.userId מערכות EMM יכולות להשתמש ב-Users.delete כדי למחוק משתמשים שמנוהלים על ידי EMM.

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

כשאדמין יוצר ארגון עם חשבונות Google Play לארגונים, הוא לא יכול להשתמש בחשבון Google Workspace. החשבון שבו הם משתמשים הופך לבעלים של הארגון, והבעלים יכול להוסיף עוד בעלים ואדמינים ב-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, ליצור טוקן אימות ולהוסיף את החשבון למכשיר.

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

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

   com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED

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

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

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

---

חשבונות Google

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

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

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

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

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

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

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

אם הארגון משתמש ב-Microsoft Active Directory ורוצה שהסיסמאות של המשתמשים ב-Google Workspace יסונכרנו עם הסיסמאות שלהם ב-Active Directory, אפשר לעיין במאמר בנושא הכנה לשימוש בסנכרון סיסמאות.

הוראות לאדמינים לגבי GCDS מופיעות במאמר מתן הרשאה לחשבון Google.

Google Directory API

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

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

  תרחיש 1 ותרחישי אימות של כניסה יחידה (SSO) מבוססת-SAML מתארים את המצב הזה בצורה מלאה יותר.

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

• שימוש ב-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 Enterprise לעובדים, כתובות האימייל והסיסמאות לרשת של המשתמשים כבר מסונכרנות בכל החשבונות שהמשתמשים צריכים לגשת אליהם.

תרחישי אימות של כניסה יחידה (SSO) מבוססת-SAML

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

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

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

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