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

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

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

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

---

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

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

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

טבלה 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 מנוהלים בכל מכשירי Android Enterprise שבהם משתמשים עובדים עם זהות ארגונית.

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

שיפורים בהרשמה

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

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

ביצענו את השינויים הבאים:

• האימות של משתמש הקצה במהלך שיוך מכשיר לארגון מטופל עכשיו על ידי Google/Android. הכלי Device Policy Controller ‏ (DPC) של EMM דורש שמערכת Android תאמת את המשתמש בנקודה המתאימה, ואז מערכת Android מחזירה את הזהות של המשתמש המחובר אל DPC.

• כשמבקשים אימות משתמש, מערכת ה-EMM צריכה להעביר טוקן הרשמה ל-Android. הטוקן הזה מוחזר על ידי קריאה ל-Android Enterprise API, ויכול להיות שהוא מוצפן במטען הייעודי (payload) של קוד ה-QR, של NFC או של ההרשמה ללא מגע.

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

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

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

יתרונות

התהליך החדש כולל את השיפורים העיקריים הבאים:

• הרשמה פשוטה יותר: השיטה הזו מצמצמת את מספר השלבים הידניים ואת המורכבות בהשוואה לשיטות הרגילות.

• תמיכה בחשבונות Google: עכשיו אפשר להשתמש בחשבונות Google בכל שיטות ההקצאה. כך לא צריך חשבונות מנוהלים ב-Google Play.

• חוויית משתמש משופרת: עם חשבונות Google מנוהלים, אתם מקבלים חוויית שימוש עשירה יותר ב-Android, שכוללת תכונות עוצמתיות למכשירים שונים, כמו שיתוף והעתקה והדבקה.

הטמעה של חשבונות משתמשים

במאמר הטמעה של חשבונות משתמשים מוסבר איך להמשיך בתהליך ההרשמה החדש.

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

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

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

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

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

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

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

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

הוראות למנהלים לגבי GCDS מופיעות במאמר מידע על Google Cloud Directory Sync.

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

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

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