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

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

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

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

סקירה כללית

תהליך משופר של שיוך מכשירים לארגון מאפשר להגדיר מכשירים בצורה יעילה יותר באמצעות כמה רכיבים חדשים ושינוי באופן ההטמעה של בקרי לניהול מדיניות מכשירים (DPC) בהתאמה אישית. הגישה החדשה הזו מחייבת פתרונות DPC מותאמים אישית שישתלבו עם Android Management API (AMAPI) SDK ועם ‏Device Policy למכשירי Android כדי לבצע פונקציות של הכנת המכשיר ורישום משתמשים.

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

אפליקציית ‏Device Policy למכשירי Android ממלאת עכשיו תפקיד מרכזי בטיפול בפעולות בצד המכשיר. ‫AMAPI SDK משמש לניהול ההתקנה והעדכונים הנדרשים במכשיר. בנוסף, האפליקציה ‏Device Policy למכשירי Android משתלטת על תהליך אימות המשתמש, מטפלת באימות המשתמש ישירות ומספקת את זהות המשתמש ל-EMM. אם Google לא מצליחה לאמת את המשתמש מסיבה כלשהי, נוצר חשבון חדש ב-Google Play לארגונים והוא מתווסף למכשיר כגיבוי.

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

שילוב API

לפני שמתחילים, חשוב לוודא שמשתמשים בגרסה העדכנית ביותר של לקוח Play EMM API ושל AMAPI SDK.

מדריך הטמעה של רישום

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

הכנת הסביבה

לפני שמתחילים בהגדרת החשבון, צריך להכין את סביבת המכשיר. ההכנה הזו כוללת עדכון של חנות Play לגרסה האחרונה והתקנה שקטה של ‏Device Policy למכשירי Android‏ (com.google.android.apps.work.clouddpc) במכשיר. התקנת ‏Device Policy למכשירי Android חיונית כי היא מכילה רכיבים קריטיים בתהליך הגדרת החשבון. אין צורך לבצע הכנה ידנית של הסביבה במערכות EMM. במקום זאת, הם צריכים להשתמש ב-EnvironmentClient, כפי שמתואר בכתובת, ולפעול לפי דוגמאות הקוד שמופיעות שם.

קוד לדוגמה

כדי להשתמש ב-API‏ AccountSetup כדי להוסיף את החשבון של מקום עבודה למכשיר, קודם כול ה-DPC צריך לוודא שהסביבה של המכשיר מוכנה.

  • משתמשים ב-EnvironmentClientFactory כדי ליצור מופע של EnvironmentClient ולקרוא ל-prepareEnvironment או ל-prepareEnvironmentAsync

    val notificationReceiverServiceName = ComponentName(context,
NotificationReceiver::class.java)

// An EMM should implement android.app.admin.DeviceAdminReceiver and use that
// class to instantiate a ComponentName

val admin = ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java)

EnvironmentClientFactory.create(context)
    .prepareEnvironment(
        PrepareEnvironmentRequest.builder()
            .setRoles(
                listOf(
                    Role.builder().setRoleType(
                        Role.RoleType.DEVICE_POLICY_CONTROLLER
                    ).build()
                )
            )
    .setAdmin(admin)
            .build(),
          notificationReceiverServiceName,
        )

[Proceed with AccountSetup]

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

תהליך ההרשמה

מערכות EMM צריכות להפסיק להשתמש ב-users.generateAuthenticationToken() וב-users.insert() בכל המכשירים. במקום זאת, מערכות EMM צריכות לקרוא ל-API במכשיר כדי לבצע אימות של משתמשי קצה. ממשק ה-API החדש יחזיר את userId ואת email אל ה-DPC. אם Google לא מצליחה לאמת את המשתמש, ייווצר חשבון Google Play לארגונים והוא יתווסף למכשיר. במקרה כזה, Google תחזיר את userId של החשבון הזה.

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

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

שילוב אופייני של DPC עם ממשקי API קודמים
איור 1. שילוב אופייני של DPC עם ממשקי API קודמים
דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירים ללא משתמש
איור 2. דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירים ללא משתמש
דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירי משתמשים
איור 3. דוגמה לשילוב של DPC עם ממשקי API חדשים למכשירי משתמשים

תהליך ההרשמה המשופר של DPC בהתאמה אישית כולל את השלבים הבאים:

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

סטטוס ברירת המחדל 'מושבת' והדרישה שלאחר מכן שמערכת ה-EMM תסמן את המכשיר כעומד בדרישות (למשל, על ידי קריאה ל-Devices.SetState) רלוונטיים במיוחד בתנאים הבאים:

  1. הארגון אימת את הבעלות על הדומיין שלו ב-Google.
  2. אדמין ה-IT הפעיל באופן מפורש ניהול ניידים של מכשירי Android של צד שלישי עבור היחידה הארגונית הספציפית של המשתמש במסוף Google Admin.
  1. יצירת טוקן רישום: מערכת ה-EMM יוצרת טוקן רישום באמצעות Play EMM API.
  2. הכנת הסביבה: ב-DPC המותאם אישית נעשה שימוש בתהליך הכנת הסביבה כדי לוודא שהמכשיר מוכן להרשמה.
  3. התחלת ההרשמה: ה-DPC המותאם אישית מפעיל את startAccountSetup API ב-AMAPI SDK, ומעביר את אסימון ההרשמה. הערה: לפני שקוראים ל-API הזה, ה-DPC צריך להיות בעלים של המכשיר או בעלים של הפרופיל.
  4. הפעלת פעילות אימות של Google: אם נדרש, ה-DPC בהתאמה אישית מפעיל את ה-API‏ launchAuthenticationActivity ב-AMAPI SDK, ומעביר את AccountSetupAttempt. הפעולה הזו מתחילה פעילות אימות של Google, ומחזירה את המשתמש ל-DPC המותאם אישית אחרי שהאימות מצליח. המשתמש יכול גם לדלג על התהליך הזה. במקרה כזה, חשבון Google Play לארגונים יתווסף למכשיר. אפשר להגדיר את האפשרות הזו באמצעות googleAuthenticationOptions.
  5. סיום הרישום: AMAPI SDK מודיע ל-DPC המותאם אישית על תוצאת הרישום.

  6. הפעלת שירותי Google: אחרי שאמצעי ה-DPC בהתאמה אישית יקצה את המכשיר באופן מלא ויאשר שהוא עומד בכל כללי המדיניות הארגונית, שרת ה-EMM חייב להפעיל את Devices.setState() עם הפרמטר accountState שהוגדר ל-"enabled".

    • למה זה חשוב: קריאה ל-API הזו מסמנת את המכשיר כעומד בדרישות.
    • התוצאה של אי ביצוע השיחה: אם לא תתקשר/י אלינו, החשבון יישאר במצב 'מושבת'.Devices.setState(setStateRequest) המשתמש לא יוכל לגשת אל Google Play (כדי להתקין או לעדכן אפליקציות) ואל שירותים אחרים של Google שמחייבים אימות החשבון.

ניהול מצב המכשיר והגישה לשירות

אחרי ההרשמה הראשונית, מערכת ה-EMM אחראית לשמירה על הגישה של המכשיר לשירותי Google בהתאם לסטטוס התאימות שלו.

טיפול בהפרעות בשירות: BAD_DEVICE_MANAGEMENT

אם הגישה של מכשיר לשירותי Google נחסמת, ‏Google Play Services‏ (GMSCore) ישדר Intent עם הפעולה: com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT. יכולות להיות לכך כמה סיבות:

  • ה-EMM אף פעם לא קרא ל-Devices.setState("enabled") אחרי שיוך המכשיר לארגון הראשוני.
  • המכשיר כבר לא עומד בדרישות של מדיניות ה-EMM, וה-EMM עדיין לא הפעיל אותו מחדש.
  • ה-EMM הגדיר באופן מפורש את מצב המכשיר כ'מושבת' על ידי קריאה ל-Devices.setState() עם accountState שהוגדר כ'מושבת'. יכול להיות שהסיבה לכך היא בעיות אבטחה, פעולות ניהוליות או סיבות אחרות.

ה-Intent הזה כולל קוד סטטוס, כמו "ThirdPartyDeviceManagementRequired".

ב-DPC בהתאמה אישית חובה להטמיע BroadcastReceiver כדי להאזין ל-Intent‏ BAD_DEVICE_MANAGEMENT הזה.

כשמקבלים את ההודעה הזו, ה-DPC צריך:

  1. הערכה מחדש של התאימות: בודקים אם המכשיר עומד כרגע בכל כללי המדיניות שהוגדרו על ידי פתרון ה-EMM.
  2. פעולה שצריך לבצע:
    • אם התאימות נשמרת: בקר ה-DPC צריך לשלוח הודעה לשרת ה-EMM. לאחר מכן, שרת ה-EMM צריך לקרוא ל-Devices.setState() עם accountState שמוגדר ל-"enabled" עבור מזהה המשתמש ומזהה המכשיר הספציפיים, כדי לנסות לשחזר את הגישה לשירות.
    • אם המכשיר לא עומד בדרישות: אחרי שהבעיות נפתרות והמכשיר עומד בדרישות, מערכת ה-EMM צריכה להתקשר אל Devices.setState().

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

שיקולים לגבי השתלטות על ארגון

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

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

הגדרת חשבון – קוד לדוגמה

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

    // Create AccountSetupClient
val client = AccountSetupClientFactory.create(
    this,
    activityResultRegistry
)
lifecycle.addObserver(client.lifecycleObserver)

// Create adminComponent
val notificationReceiver = ComponentName(this, AccountSetupNotificationReceiver::class.java)
// Helper method to get enrollment token created with Play EMM API
val enrollmentToken = getEnrollmentToken()
val request =
    StartAccountSetupRequest.builder()
        .setEnrollmentToken(enteredText)
        .setNotificationReceiverServiceComponentName(notificationReceiver)
        .setAdminComponentName(
            ComponentName(this, com.example.dpc.DeviceAdminReceiver::class.java))
        .build()
try {
    val accountSetupAttempt = client.startAccountSetup(request)
    // handle attempt
} catch (e: Exception) {
    // handle exception
}

  2. מטמיעים את הממשק AccountSetupListener ומספקים יישום לטיפול בעדכוני הסטטוס שהתקבלו.

  3. ‫Extend NotificationReceiverService ומספקים את המופע AccountSetupListener שנוצר בשלב 2 על ידי החלפת getAccountSetupListener().

    // Handles account setup changes
class AccountSetupNotificationReceiver :
      NotificationReceiverService(),
      AccountSetupListener {

    override fun getAccountSetupListener(): AccountSetupListener = this

    override fun onAccountSetupChanged(accountSetupAttempt:
  AccountSetupAttempt) {

        when (accountSetupAttempt.state.kind) {
            StateCase.ADDED_ACCOUNT -> {
                val enterpriseAccount = state.addedAccount()
                val userId = enterpriseAccount.userId
                val deviceId = enterpriseAccount.deviceId
                // Handle account added state.

                // IMPORTANT: The device/account is now added but *DISABLED*
                // for Google services. Your EMM backend MUST be notified to
                // perform policy compliance checks and then call Devices.setState()
                // to activate Google Play and other services.

            }
            StateCase.AUTHENTICATION_ACTIVITY_LAUNCH_REQUIRED -> {
                val request = LaunchAuthenticationActivityRequest.builder()
            .setAccountSetupAttempt(accountSetupAttempt)
            .build();
                // Send the attempt to the foreground activity to call:
                accountSetupClient.launchAuthenticationActivity(request)
            }
            StateCase.ACCOUNT_SETUP_ERROR -> {
                // Handle error state.
                val failureReason = state.accountSetupError().failureReason
            }
            else -> {
                // Handle unknown account setup attempt state.
            }
        }
    }
}

  4. מוסיפים את הכיתה המורחבת NotificationReceiverService ל-AndroidManifest.xml ומוודאים שהיא מיוצאת.

      <application>
    <service
        android:name = ".accountsetup.AccountSetupNotificationReceiver"
        android:exported = "true" />
  </application>

    אם האפליקציה מטרגטת SDK בגרסה 30 ואילך, צריך להוסיף רכיב queries ל-AndroidManifest.xml כדי לציין שהיא תבצע אינטראקציה עם ADP.

      <queries>
    <package android:name="com.google.android.apps.work.clouddpc" />
  </queries>

הנחיות לבדיקה

בקטע הזה מפורטות הנחיות ושיטות מומלצות לבדיקת ההטמעה.

בדיקה של PrepareEnvironment

  1. קבלת המצב הנוכחי של המכשיר: מערכת ה-EMM מפעילה

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    כדי לקבל את הגרסה של ‏Device Policy למכשירי Android שמותקנת במכשיר. אם ‏Device Policy למכשירי Android לא מותקנת, צפוי פלט ריק.

  2. שילוב של PrepareEnvironment: ה-DPC המותאם אישית מפעיל את prepareEnvironment API ב-AMAPI SDK, ומעביר את הבקשה הנכונה.

  3. המתנה לתוצאה של PrepareEnvironment: ה-DPC המותאם אישית ממתין לסיום של prepareEnvironment.

  4. מאשרים שהפעולה PrepareEnvironment הושלמה בהצלחה: בסיום, שירות ה-EMM פועל שוב

    adb shell dumpsys package com.google.android.apps.work.clouddpc | grep versionName

    הפעם גרסת ‏Device Policy למכשירי Android צריכה להיות גבוהה יותר מהגרסה בשלב 1.

בדיקת אימות של חשבון Google

  1. יצירת ארגון לבדיקה: פתרון ה-EMM יוצר דומיין לבדיקה של ארגון Google שמקושר לפתרון EMM לבדיקה, עם enterprises.generateSignupUrl.
  2. הפעלת אימות Google: פלטפורמת ה-EMM מפעילה אימות Google עבור ארגון הבדיקה בהתאם להוראות האלה במסוף Google Admin.
  3. יצירת טוקן הרשמה: מערכת ה-EMM יוצרת טוקן הרשמה באמצעות Play EMM API עם הסוג userDevice.
  4. התחלת ההרשמה: ה-DPC המותאם אישית מפעיל את startAccountSetup API ב-AMAPI SDK, ומעביר את אסימון ההרשמה.
  5. נדרשת פעילות הפעלה: ה-SDK של AMAPI מודיע ל-DPC המותאם אישית שצריך להפעיל פעילות כדי לאמת את המשתמש.
  6. אימות המשתמש: ה-DPC המותאם אישית מפעיל את launchAuthenticationActivity כדי להתחיל את הפעילות. המשתמש מאומת באמצעות חשבון Google מנוהל (חלק מהארגון שנוצר בשלב 1).
  7. סיום הרישום: AMAPI SDK מודיע ל-DPC המותאם אישית על תוצאת הרישום.

בדיקת דילוג על אימות Google

נשתמש בהגדרה שתוארה קודם.

הפעם, בשלב 7, המשתמש לוחץ על דילוג במקום לבצע אימות באמצעות חשבון Google שלו. הצירוף מסתיים בהצלחה, עם חשבון שירות במכשיר (כלומר, AuthenticationType הוא אנונימי).

בדיקת מכשירים ללא משתמשים

תהליך ההרשמה המשופר של DPC בהתאמה אישית כולל את השלבים הבאים, כשאימות Google מושבת:

  1. יצירת חשבון בדיקה לארגון: אפשר להשתמש באותו חשבון ארגון שנוצר קודם.
  2. יצירת טוקן הרשמה: מערכת ה-EMM יוצרת טוקן הרשמה באמצעות Play EMM API עם הסוג userlessDevice.
  3. התחלת ההרשמה: ה-DPC המותאם אישית מפעיל את startAccountSetup API ב-AMAPI SDK, ומעביר את אסימון ההרשמה.
  4. סיום הרישום: AMAPI SDK מודיע ל-DPC המותאם אישית על תוצאת הרישום.