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

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

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

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

---

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

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

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

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

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

---

חשבונות 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 ו-Android framework API, בכל הרכיבים של פתרון ה-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. מזהה החשבון חייב להיות ערך ייחודי בכל המערכת. אל תשתמשו בפרטים אישיים מזהים במזהה החשבון.
      • ה-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 אחד ונרשם אצל ספק אחר, ה-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 מנוהלים. במקרה כזה, המכשיר וחשבונות המשתמשים שמשויכים לארגון נמחקים בסופו של דבר, כפי שמתואר בקטע ביטול הרשמה, רישום מחדש, מחיקה.

תפוגת החשבון

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

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

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

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

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

   com.google.android.gms.auth.ACCOUNT_REAUTH_REQUIRED

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

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

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

---

חשבונות Google

במקרה של ארגונים שמשתמשים בחשבונות Google, חשבונות המשתמשים בפתרון EMMEMM משקפים חשבונות משתמשים קיימים שמשויכים לשירות Google אחר (למשל, G Suite). החשבונות האלה הם 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 כדי לסנכרן את הנתונים בדומיין שלו ב-G Suite עם הנתונים שבספריית ה-LDAP. לחלופין, אפשר להשתמש ב-GCDS כדי לעשות זאת בשם הארגון, אם הארגון נותן לכם גישה.

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

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

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

ממשק API של ספריית Google

בפריסה של חשבונות 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 חדש, הארגון מוסיף את המשתמש לספריית ה-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, יכול להיות שאתם או הלקוח שלכם ישתמשו ב-Security Assertion Markup Language (SAML) עם ספק זהויות (IdP) כדי לאמת את חשבון Google שמשויך לכל משתמש. השמות של חשבונות Google משמשים לאימות קיום חשבונות Google של המשתמשים, לצורך אימות המשתמשים כשהם נכנסים למכשירים שלהם. לדוגמה, אפשר להשתמש ב-SAML בתרחיש 2. למידע על הגדרת הממשק, קראו את המאמר הגדרת כניסה יחידה לחשבונות G Suite.

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

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

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