پیاده سازی حساب های کاربری

دو نوع هویت کاربری اصلی برای ثبت‌نام‌های سازمانی اندروید وجود دارد: حساب‌های کاربری مدیریت‌شده گوگل پلی و حساب‌های کاربری مدیریت‌شده گوگل. حساب‌های کاربری مدیریت‌شده گوگل پلی دستگاه‌محور هستند، به این معنی که به هویت گوگل یک کاربر خاص گره نخورده‌اند. در مقابل، حساب‌های کاربری مدیریت‌شده گوگل به هویت سازمانی گوگل کاربر متصل هستند که با لاگین نگه‌داشتن کاربر در دستگاه‌هایش، تجربه کاربری را بهبود می‌بخشد.

حساب‌های کاربری مدیریت‌شده‌ی گوگل پلی قبلاً استاندارد بودند. با این حال، گوگل اکنون تمام توسعه‌دهندگان جدید را تشویق می‌کند تا از روند ثبت‌نام بهبودیافته استفاده کنند که به‌طور پیش‌فرض به ایجاد حساب‌های کاربری مدیریت‌شده‌ی گوگل محدود می‌شود.

اگرچه راهنمایی برای پیاده‌سازی قدیمی‌تر در انتهای این سند برای درک بهتر موضوع ارائه شده است، اما تمام توسعه‌های جدید باید از جریان ثبت‌نام جدید که در اینجا به تفصیل شرح داده شده است، پیروی کنند.

نمای کلی

جریان بهبود یافته ثبت نام دستگاه، با بهره‌گیری از چندین مؤلفه جدید و تغییر نحوه پیاده‌سازی کنترل‌کننده‌های سیاست دستگاه (DPC) سفارشی، راه‌اندازی دستگاه را ساده می‌کند. این رویکرد جدید نیازمند ادغام راه‌حل‌های DPC سفارشی با SDK رابط برنامه‌نویسی نرم‌افزار مدیریت اندروید (AMAPI) و سیاست دستگاه اندروید برای انجام آماده‌سازی دستگاه و عملکردهای ثبت نام کاربر است.

کیت توسعه نرم‌افزار AMAPI، رابط‌های برنامه‌نویسی کاربردی (API) لازم برای تعامل با خط‌مشی دستگاه اندروید (Android Device Policy) را در خود دستگاه فراهم می‌کند. در سمت سرور، راهکارهای مدیریت تحرک سازمانی (EMM) از رابط برنامه‌نویسی کاربردی Play EMM برای تولید توکن‌های ثبت‌نام مورد نیاز برای شروع فرآیند ثبت‌نام دستگاه استفاده خواهند کرد.

برنامه‌ی Android Device Policy اکنون نقش محوری در مدیریت عملیات سمت دستگاه ایفا می‌کند. AMAPI SDK برای مدیریت نصب و به‌روزرسانی‌های لازم روی دستگاه استفاده می‌شود. Android Device Policy همچنین جریان احراز هویت کاربر را بر عهده می‌گیرد، احراز هویت کاربر را مستقیماً مدیریت می‌کند و هویت کاربر را به EMM ارائه می‌دهد. اگر گوگل به هر دلیلی نتواند کاربر را احراز هویت کند، یک حساب Google Play مدیریت‌شده‌ی جدید ایجاد و به عنوان جایگزین به دستگاه اضافه می‌شود.

بخش کلیدی این جریان ثبت‌نام جدید، مدیریت دسترسی دستگاه به سرویس‌های گوگل است. به‌طور پیش‌فرض، دستگاه‌ها در حالت محدود راه‌اندازی می‌شوند و EMM نقش مهمی در فعال کردن دسترسی پس از انطباق دستگاه با قوانین ایفا می‌کند.

ادغام API

قبل از شروع، مطمئن شوید که از آخرین نسخه کلاینت Play EMM API و AMAPI SDK استفاده می‌کنید.

راهنمای اجرای ثبت نام

این راهنما مراحل لازم برای پیاده‌سازی ثبت نام (enrollment) را ارائه می‌دهد. این راهنما شامل آماده‌سازی محیط، مدیریت روش‌های مختلف ثبت نام و مدیریت چرخه حیات دستگاه می‌شود.

آماده سازی محیط

قبل از شروع تنظیم حساب کاربری، لازم است محیط دستگاه را آماده کنید. این آماده‌سازی مستلزم به‌روزرسانی فروشگاه Play به آخرین نسخه آن و نصب بی‌سروصدای Android Device Policy ( com.google.android.apps.work.clouddpc ) روی دستگاه است. نصب Android Device Policy ضروری است زیرا اجزای حیاتی فرآیند تنظیم حساب کاربری را در خود جای داده است. EMMها نیازی به آماده‌سازی دستی محیط ندارند. در عوض، آنها باید از EnvironmentClient ، همانطور که در [لینک] مستند شده است، استفاده کنند و به نمونه‌های کد ارائه شده پایبند باشند.

کد نمونه

قبل از اینکه بتوانید از AccountSetup API برای اضافه کردن حساب کاری روی دستگاه استفاده کنید، 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]

این عملیات ممکن است چند ثانیه یا چند دقیقه طول بکشد، زیرا ممکن است برنامه‌هایی برای تأیید محیط کاری مناسب نصب یا به‌روزرسانی شوند. گوگل توصیه می‌کند این فرآیند را در اسرع وقت در پس‌زمینه شروع کنید و در حالی که کاربر منتظر است، رابط کاربری مناسب را نشان دهید. پس از اتمام عملیات، دستگاه آماده است تا DPC از API AccountSetup استفاده کند.

جریان ثبت نام

EMMها باید استفاده از users.generateAuthenticationToken() و users.insert() را برای همه دستگاه‌ها متوقف کنند. در عوض، EMMها باید API روی دستگاه را برای انجام احراز هویت کاربر نهایی فراخوانی کنند. API جدید userId و email به DPC برمی‌گرداند. اگر گوگل نتواند کاربر را احراز هویت کند، یک حساب Google Play مدیریت‌شده ایجاد و به دستگاه اضافه می‌شود. در این حالت، گوگل userId آن حساب را برمی‌گرداند.

گوگل اکنون استفاده از توکن‌های ثبت‌نام را معرفی می‌کند که باید به API احراز هویت ارسال شوند. EMMها زمان و نحوه ایجاد توکن را تعیین می‌کنند و می‌توانند بخشی از یک payload ثبت‌نام موجود باشند (مثلاً یک کد QR یا پیکربندی Zero-touch).

با این حال، گوگل توصیه می‌کند که توکن را بنا به تقاضا ایجاد کنید و API موجود برای حساب‌های مدیریت‌شده‌ی گوگل پلی را با API جدید جایگزین کنید تا تغییرات به حداقل برسد.

ادغام معمول DPC با API های قبلی
شکل ۱. ادغام معمول DPC با API های قبلی
مثالی از ادغام DPC با APIهای جدید برای دستگاه‌های بدون کاربر
شکل ۲. نمونه‌ای از ادغام DPC با APIهای جدید برای دستگاه‌های بدون کاربر
مثالی از ادغام DPC با APIهای جدید برای دستگاه‌های کاربر
شکل ۳. مثالی از ادغام DPC با APIهای جدید برای دستگاه‌های کاربر

روند بهبود یافته ثبت نام DPC سفارشی شامل مراحل زیر است:

وضعیت اولیه مهم دستگاه: هنگام ثبت دستگاه با DPC سفارشی، حساب گوگل اضافه شده به دستگاه در حالت غیرفعال شروع به کار می‌کند. این بدان معناست که دسترسی به سرویس‌های گوگل، از جمله گوگل پلی، در ابتدا محدود می‌شود.

این وضعیت پیش‌فرض «غیرفعال» و الزام بعدی برای EMM جهت علامت‌گذاری دستگاه به عنوان سازگار (مثلاً با فراخوانی Devices.SetState) به‌طور خاص تحت این شرایط قابل اجرا هستند:

  1. این سازمان مالکیت دامنه خود را نزد گوگل تأیید کرده است.
  2. مدیر فناوری اطلاعات صراحتاً مدیریت موبایل اندروید شخص ثالث را برای واحد سازمانی (OU) خاص کاربر در کنسول مدیریت گوگل فعال کرده است.
  1. ایجاد توکن ثبت نام: EMM با استفاده از API مربوط به Play EMM، یک توکن ثبت نام ایجاد می‌کند.
  2. آماده‌سازی محیط: DPC سفارشی از جریان آماده‌سازی محیط برای تأیید آمادگی دستگاه برای ثبت‌نام استفاده می‌کند.
  3. شروع ثبت‌نام: DPC سفارشی، API startAccountSetup را در AMAPI SDK فراخوانی می‌کند و توکن ثبت‌نام را ارسال می‌کند. توجه: DPC قبل از فراخوانی این API باید یا مالک دستگاه باشد یا مالک پروفایل.
  4. راه‌اندازی فعالیت احراز هویت گوگل: در صورت نیاز، DPC سفارشی، API launchAuthenticationActivity را در AMAPI SDK فراخوانی می‌کند و AccountSetupAttempt را ارسال می‌کند. این کار یک فعالیت احراز هویت گوگل را آغاز می‌کند و پس از احراز هویت موفقیت‌آمیز، کاربر را به DPC سفارشی بازمی‌گرداند. کاربر همچنین می‌تواند از این فرآیند صرف نظر کند. در این حالت، یک حساب Google Play مدیریت‌شده به دستگاه اضافه می‌شود. این گزینه را می‌توان با استفاده از googleAuthenticationOptions پیکربندی کرد.
  5. نهایی کردن ثبت نام: AMAPI SDK نتیجه ثبت نام را به DPC سفارشی اطلاع می‌دهد.

  6. فعال کردن سرویس‌های گوگل: پس از اینکه DPC سفارشی، دستگاه را به طور کامل آماده‌سازی و تأیید کرد که با تمام سیاست‌های سازمانی مطابقت دارد، سرور EMM باید Devices.setState() را با پارامتر accountState که روی "enabled" تنظیم شده است، فراخوانی کند.

    • چرا این امر ضروری است: این فراخوانی API، دستگاه را به عنوان سازگار علامت‌گذاری می‌کند.
    • پیامد عدم فراخوانی: بدون فراخوانی Devices.setState(setStateRequest) ، حساب در حالت "غیرفعال" باقی می‌ماند. کاربر قادر به دسترسی به Google Play (برای نصب یا به‌روزرسانی برنامه‌ها) و سایر سرویس‌های Google که نیاز به احراز هویت حساب دارند، نخواهد بود.

مدیریت وضعیت دستگاه و دسترسی به سرویس

پس از ثبت اولیه، EMM مسئول حفظ دسترسی دستگاه به سرویس‌های گوگل بر اساس وضعیت انطباق آن است.

مدیریت اختلالات سرویس: مدیریت بد دستگاه (BAD_DEVICE_MANAGEMENT)

اگر دسترسی دستگاهی به سرویس‌های گوگل مسدود شده باشد، سرویس‌های گوگل پلی (GMSCore) یک Intent با اکشن زیر ارسال می‌کنند: com.google.android.gms.auth.BAD_DEVICE_MANAGEMENT . این اتفاق می‌تواند به دلایل مختلفی رخ دهد:

  • EMM پس از ثبت اولیه دستگاه، هرگز Devices.setState("enabled") را فراخوانی نکرد.
  • این دستگاه دیگر با سیاست‌های EMM مطابقت ندارد و EMM هنوز آن را دوباره فعال نکرده است.
  • EMM با فراخوانی Devices.setState() و تنظیم accountState روی "disabled"، وضعیت دستگاه را به صراحت روی "disabled" تنظیم کرد. این ممکن است به دلیل نگرانی‌های امنیتی، اقدامات مدیریتی یا دلایل دیگر باشد.

این Intent شامل یک کد وضعیت مانند "ThirdPartyDeviceManagementRequired" است.

DPC های سفارشی باید یک BroadcastReceiver را برای گوش دادن به این هدف BAD_DEVICE_MANAGEMENT پیاده سازی کنند.

پس از دریافت این پخش، DPC باید:

  1. ارزیابی مجدد انطباق: بررسی کنید که آیا دستگاه در حال حاضر تمام سیاست‌های تعیین‌شده توسط EMM را رعایت می‌کند یا خیر.
  2. اقدام کنید:
    • در صورت مطابقت: DPC باید به سرور EMM اطلاع دهد. سپس سرور EMM باید Devices.setState() را با تنظیم accountState روی "enabled" برای شناسه کاربری و شناسه دستگاه خاص فراخوانی کند تا تلاش کند دسترسی به سرویس را بازیابی کند.
    • اگر سازگار نباشد: پس از حل مشکلات و سازگار شدن دستگاه، EMM باید Devices.setState() را فراخوانی کند.

این مکانیزم تضمین می‌کند که راهی برای تشخیص و بازیابی موقعیت‌هایی که دستگاه دسترسی به سرویس‌های گوگل را از دست می‌دهد، وجود دارد.

ملاحظات مربوط به تصاحب شرکت

ممکن است تغییراتی در نوع حساب کاربری سازمان (مثلاً از ManagedGoogleDomainType.TYPE_TEAM به ManagedGoogleDomainType.TYPE_DOMAIN ) رخ دهد. اگرچه این فرآیند معمولاً اتصال EMM را مختل نمی‌کند، اما گاهی اوقات می‌تواند دسترسی به سرویس گوگل را در دستگاه‌ها مختل کند.

مدیران EMM باید آگاه باشند که اگر کاربران پس از یک رویداد تصاحب شناخته‌شده، مشکلات دسترسی به سرویس را گزارش دهند، حتی اگر دستگاه با سیاست‌های EMM سازگار به نظر برسد، ممکن است فراخوانی Devices.setState() برای همگام‌سازی مجدد وضعیت دستگاه با backendهای گوگل تحت ساختار جدید مشتری ضروری باشد. فراخوانی‌های پیشگیرانه برای همه دستگاه‌ها پس از تصاحب عموماً ضروری نیستند، اما ابزاری کلیدی برای حل مشکلات دسترسی است.

تنظیم حساب کاربری - نمونه کد

  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. NotificationReceiverService بسط داده و نمونه AccountSetupListener ایجاد شده در مرحله 2 را با override کردن 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 یا بالاتر را هدف قرار داده است، در این صورت یک عنصر query در 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 سفارشی، API prepareEnvironment را در AMAPI SDK فراخوانی می‌کند و درخواست صحیح را ارسال می‌کند.

  3. نتیجه Await PrepareEnvironment: DPC سفارشی منتظر تکمیل prepareEnvironment می‌ماند.

  4. تأیید موفقیت PrepareEnvironment: پس از اتمام، EMM دوباره اجرا می‌شود

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

    این بار نسخه خط‌مشی دستگاه اندروید باید بالاتر از مرحله ۱ باشد.

تست احراز هویت حساب گوگل

  1. ایجاد یک دامنه آزمایشی سازمانی: EMM یک دامنه آزمایشی Google enterprise ایجاد می‌کند که به یک EMM آزمایشی با استفاده از enterprises.generateSignupUrl متصل است.
  2. فعال کردن احراز هویت گوگل: EMM با دنبال کردن این دستورالعمل‌ها در کنسول مدیریت گوگل، احراز هویت گوگل را برای شرکت آزمایشی فعال می‌کند.
  3. ایجاد توکن ثبت نام: EMM با استفاده از API مربوط به Play EMM و از نوع userDevice ، یک توکن ثبت نام ایجاد می‌کند.
  4. شروع ثبت‌نام: DPC سفارشی، API startAccountSetup را در AMAPI SDK فراخوانی می‌کند و توکن ثبت‌نام را ارسال می‌کند.
  5. فعالیت مورد نیاز برای راه‌اندازی: AMAPI SDK به DPC سفارشی اطلاع می‌دهد که برای احراز هویت کاربر باید فعالیتی راه‌اندازی شود.
  6. احراز هویت کاربر: DPC سفارشی، launchAuthenticationActivity برای شروع فعالیت فراخوانی می‌کند. کاربر با یک حساب Google مدیریت‌شده (بخشی از شرکت ایجاد شده در مرحله 1) احراز هویت می‌شود.
  7. نهایی کردن ثبت نام: AMAPI SDK نتیجه ثبت نام را به DPC سفارشی اطلاع می‌دهد.

تست رد کردن احراز هویت گوگل

ما از تنظیماتی که قبلاً توضیح داده شده استفاده خواهیم کرد.

این بار، در مرحله ۷، کاربر به جای تأیید اعتبار با حساب گوگل خود، روی «رد شدن» کلیک می‌کند. ثبت نام با موفقیت انجام می‌شود، با یک حساب کاربری سرویس روی دستگاه (یعنی AuthenticationType ناشناس است).

آزمایش دستگاه‌های بدون کاربر

روند بهبود یافته ثبت نام DPC سفارشی، در صورت غیرفعال بودن احراز هویت گوگل، از مراحل زیر استفاده می‌کند:

  1. ایجاد یک شرکت آزمایشی: این می‌تواند همان شرکتی باشد که قبلاً ایجاد شده است.
  2. ایجاد توکن ثبت نام: EMM با استفاده از API مربوط به Play EMM و از نوع userlessDevice ، یک توکن ثبت نام ایجاد می‌کند.
  3. شروع ثبت‌نام: DPC سفارشی، API startAccountSetup را در AMAPI SDK فراخوانی می‌کند و توکن ثبت‌نام را ارسال می‌کند.
  4. نهایی کردن ثبت نام: AMAPI SDK نتیجه ثبت نام را به DPC سفارشی اطلاع می‌دهد.