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

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

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

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

סקירה כללית

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

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

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

שילוב API

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

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

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

הכנת הסביבה

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

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

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

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

  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: אחרי שמכשיר של משתמש עם חשבון Google מנוהל עומד בדרישות של מדיניות ארגונית, מערכת ה-EMM צריכה להפעיל את Devices.setState(). הפעולה הזו מאפשרת לחשבון במכשיר לגשת לשירותי Google. בלי הקריאה הזו, חנות Play ושירותים אחרים של Google לא יפעלו.

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

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

            }
            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

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

  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

    הפעם גרסת Android Device Policy צריכה להיות גבוהה יותר מהגרסה בשלב 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 המותאם אישית על תוצאת הרישום.