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

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

בסביבה ארגונית של 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).לא מוגדר.
accountTypedeviceAccount, userAccountuserAccount
displayNameהשם שמוצג בפריטים בממשק המשתמש, למשל ב: Google Play. אל תשתמשו בפרטים אישיים מזהים.לא מוגדר.
managementTypeemmManagedgooglemanaged, emmManaged
primaryEmailלא מוגדר.שדה זה הוא המפתח הראשי על ידי שבו אתה מנהל את הסנכרון של משתמשים מחשבונות דומיין בניהול Google חשבונות במערכת שלך.
שיטות
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 ו-Android framework API בכל הרכיבים פתרון EMM (מסוף EMM, שרת EMM ו-DPC). הרכיבים האלה מקיימים אינטראקציה זמן ריצה ליצירת חשבון משתמש ניהול ההקצאות של פרופיל העבודה במכשיר היעד מסוף או שרת ה-EMM שלך צריכים:

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

  • אחסון המיפוי בין userId (שמוחזר מהשדה insert ) ואת accountIdentifier שבחרת.

מידע על הדרישות לגבי בקר DPC זמין במאמר פיתוח מדיניות מכשירים בקר משחקים.

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

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

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

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

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

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

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

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

כדי לשנות פרטי חשבון, צריך להתקשר 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

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

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

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

חשבונות Google

לארגונים שמשתמשים בחשבונות Google, חשבונות משתמשים ב-EMM הפתרון שמשקף חשבונות משתמשים קיימים שמשויכים לשירות אחר של 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 (GSPS) באמצעות GCDS.

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

ממשק API של Google Directory

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

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

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

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

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

שימוש ב-Directory API (עם הרשאת קריאה בלבד) וב-GCDS

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

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

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

במקרה כזה:

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

תרחיש 2: ספק EMM אחראי על מחזורי החיים של החשבון

שימוש ב-Directory API עם גישת קריאה-כתיבה

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

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

במקרה כזה:

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

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

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

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

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

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