Penyediaan identitas (atau penyediaan akun) adalah proses penyiapan akun dan pembuatan koneksi di antara tiga sistem yang menyimpan data pengguna, dan dalam beberapa kasus, penyiapan koneksi antara pengguna dan perangkat mereka.
Dalam lingkungan perusahaan Android, tiga sistem berbeda menyimpan informasi akun pengguna:
- Direktori pengguna organisasi adalah sumber informasi pasti tentang pengguna.
- Anda (penyedia solusi EMM) harus mengelola setidaknya direktori minimal pengguna organisasi.
- Google menyimpan beberapa informasi tentang Akun Google Play terkelola dan Akun Google untuk menyediakan pengelolaan aplikasi melalui Google Play.
Resource Users merepresentasikan akun
yang terkait dengan perusahaan. Akun dapat khusus untuk perangkat, atau dapat dikaitkan dengan individu yang memiliki beberapa perangkat dan menggunakan akun di semua perangkat tersebut. Akun tersebut dapat memberikan akses ke Google Play terkelola saja, atau ke layanan Google lainnya, bergantung pada cara Anda menyiapkan perusahaan pelanggan:
Akun Google Terkelola adalah akun yang sudah ada dan dikelola oleh Google. Akun ini mengharuskan pelanggan menggunakan Google sebagai penyedia identitas mereka atau menautkan direktori pengguna organisasi mereka ke Google. Untuk perusahaan yang menggunakan Akun Google terkelola, Google bertanggung jawab untuk mengautentikasi pengguna selama penyediaan perangkat.
Akun Google Play Terkelola memberikan cara bagi perusahaan untuk otomatis membuat akun pengguna terbatas melalui penyedia solusi pengelolaan mobilitas perusahaan (EMM). Akun ini hanya memberikan akses ke Google Play Terkelola. EMM bertanggung jawab sepenuhnya untuk mengautentikasi pengguna jika diperlukan. Untuk akun Google Play perusahaan terkelola, ini adalah satu-satunya jenis akun yang tersedia.
Tabel 1: Kolom dan metode Users API
| Akun Managed Google Play | Akun Google terkelola | |
|---|---|---|
| Kolom | ||
| id | ||
| jenis | ||
| accountIdentifier | ID unik yang Anda buat dan petakan
ke ID (userId) yang ditampilkan dari Google Play. Jangan gunakan informasi identitas pribadi (PII). | Belum ditetapkan. |
| accountType | deviceAccount, userAccount | userAccount |
| Nama Tampilan | Nama yang Anda tampilkan di item UI, seperti di dalam Google Play. Jangan gunakan informasi identitas pribadi. | Belum ditetapkan. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Belum ditetapkan. | Kolom ini adalah kunci utama yang digunakan untuk mengelola sinkronisasi dari akun domain yang dikelola Google ke akun pengguna di sistem Anda. |
| Metode | ||
| hapus | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| insert | ||
| list | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
Sebagai bagian dari peningkatan pendaftaran perangkat, kami beralih menggunakan Akun Google terkelola untuk semua perangkat Android Enterprise yang digunakan oleh karyawan dengan identitas perusahaan.
Untuk pendaftaran baru, sebaiknya gunakan Akun Google terkelola daripada Akun Google Play terkelola. Meskipun kami terus mendukung Akun Google Play terkelola untuk pengguna lama, akun tersebut hanya memberikan akses ke Managed Google Play Store. Akun Google Terkelola memberi pengguna akses ke rangkaian lengkap layanan Google dan fitur lintas perangkat.
Peningkatan pendaftaran
Akun Google terkelola menetapkan identitas pengguna dengan Google. Hal ini memungkinkan pengalaman lintas perangkat, seperti penyerahan tugas, notifikasi, dan berbagi di sekitar. Fitur ini semakin penting dalam ruang perusahaan, tempat pengguna sering menggunakan beberapa perangkat.
Perusahaan yang tidak menggunakan Google sebagai penyedia identitas mereka kini sangat disarankan untuk menautkan penyedia identitas yang sudah ada ke Google. Tindakan ini memungkinkan pembuatan Akun Google terkelola untuk karyawan selama proses pengikatan. Perusahaan harus menggunakan penyedia identitas yang sama untuk hal ini seperti yang mereka gunakan dengan EMM mereka.
Kami telah menerapkan perubahan berikut:
Autentikasi pengguna akhir selama pendaftaran perangkat kini ditangani oleh Google/Android. Pengontrol Kebijakan Perangkat (DPC) EMM mewajibkan Android mengautentikasi pengguna pada titik yang sesuai, lalu Android akan menampilkan identitas pengguna yang login ke DPC.
EMM harus meneruskan token pendaftaran ke Android saat meminta autentikasi pengguna. Token ini ditampilkan oleh panggilan API ke Android Enterprise API dan mungkin dienkode dalam payload pendaftaran QR, NFC, atau zero-touch.
Meskipun Android kini menangani autentikasi dan memberikan identitas pengguna ke EMM, EMM tetap bertanggung jawab untuk memetakan identitas pengguna ke grup atau struktur organisasi yang benar. Pemetaan ini sangat penting untuk menerapkan kebijakan yang sesuai ke perangkat. Oleh karena itu, perusahaan harus terus menautkan direktori pengguna organisasi mereka ke EMM mereka.
Admin IT dapat mengaktifkan atau menonaktifkan fitur autentikasi pengguna akhir baru yang disediakan Google. Untuk memberikan pengalaman terbaik kepada pengguna, termasuk fitur lintas perangkat, sebaiknya admin IT menautkan direktori pengguna organisasi mereka ke Google. Tanpa penautan ini, pengguna akan memiliki Akun Google Play terkelola dan tidak akan memiliki akses ke pengalaman lintas perangkat.
Persyaratan baru untuk semua EMM adalah memberikan informasi tambahan saat membuat token pendaftaran dan login. Khususnya, Anda kini harus menunjukkan apakah perangkat tidak memiliki pengguna (seperti kios atau perangkat khusus) atau tidak.
Manfaat
Proses baru ini menawarkan peningkatan utama berikut:
Pendaftaran yang disederhanakan: Metode ini mengurangi jumlah langkah manual dan kompleksitas dibandingkan dengan metode standar.
Dukungan Akun Google: Anda kini dapat menggunakan Akun Google dengan semua metode penyediaan. Dengan demikian, Anda tidak memerlukan Akun Google Play terkelola.
Pengalaman pengguna yang lebih baik: Dengan Akun Google terkelola, Anda mendapatkan pengalaman Android yang lebih kaya yang mencakup fitur lintas perangkat yang canggih seperti berbagi dan salin tempel.
Penerapan akun pengguna
Untuk mempelajari cara melanjutkan alur pendaftaran baru ini, lihat Menerapkan akun pengguna.
Siklus proses Akun Google terkelola
Untuk organisasi yang menggunakan Akun Google, akun pengguna dalam solusi EMM
mencerminkan akun pengguna yang ada yang terkait dengan layanan Google lain
(seperti Google Workspace). Akun ini adalah googleManaged
(Tabel 1) karena
layanan backend Google adalah sumber untuk pembuatan dan informasi
tentang akun tersebut.
Sebagai EMM, Anda dapat menyediakan mekanisme di konsol untuk memfasilitasi pembuatan dan sinkronisasi berkelanjutan akun pengguna yang ada di sistem Anda dengan sumber akun domain Google mereka menggunakan alat seperti Google Cloud Directory Sync (GCDS) dan Google Admin SDK Directory API. Lihat ringkasan berbagai pendekatan. Model identitas domain yang dikelola Google mensyaratkan bahwa akun pengguna ada dalam konteks solusi Anda (konsol EMM, server EMM, mungkin di datastore) sebelum dapat disediakan di salah satu perangkat pengguna dalam konteks profil kerja.
Selama penyediaan identitas, domain yang dikelola Google milik organisasi akan diisi dengan akun pengguna. Dalam beberapa kasus, identitas online pengguna yang sudah ada (misalnya, akun Microsoft Exchange mereka) disinkronkan dengan Akun Google mereka.
Menyinkronkan akun pelanggan
Dalam deployment Akun Google, organisasi dapat menggunakan alat GCDS untuk menyinkronkan data di domain G Suite dengan data di direktori LDAP. Atau, Anda dapat menggunakan GCDS untuk melakukannya atas nama organisasi, jika organisasi memberi Anda akses.
Alat GCDS memanggil Google Directory API dan menyinkronkan nama pengguna, tetapi tidak sandi.
Jika organisasi menggunakan Microsoft Active Directory dan ingin menyinkronkan sandi G Suite pengguna dengan sandi Active Directory mereka, mereka—atau Anda—dapat menggunakan alat G Suite Password Sync (GSPS) dengan GCDS.
Untuk mengetahui petunjuk GCDS bagi admin, lihat Menyiapkan domain G Suite untuk sinkronisasi.
Google Directory API
Dalam deployment Akun Google, Anda dapat menggunakan Google Directory API untuk menyinkronkan Active Directory, sandi, atau keduanya:
Menggunakan Directory API untuk sinkronisasi khusus direktori. Jika Anda memiliki akses hanya baca ke domain Google terkelola organisasi, Anda dapat menggunakan Google Directory API untuk mendapatkan informasi Akun Google, seperti nama pengguna (tetapi bukan sandi) dari Google. Karena Anda tidak dapat menulis data apa pun ke Akun Google pengguna, organisasi sepenuhnya bertanggung jawab atas siklus proses akun.
Skenario 1 dan skenario autentikasi SSO berbasis SAML menggambarkan situasi ini dengan lebih lengkap.
Untuk mengetahui informasi tentang cara menggunakan Directory API dengan cara ini, lihat Mengambil semua pengguna akun dalam dokumentasi Directory API.
Menggunakan Directory API untuk sinkronisasi sandi direktori dan opsional. Jika Anda memiliki akses baca-tulis ke domain Google terkelola organisasi, Anda dapat menggunakan Google Directory API untuk mendapatkan nama pengguna, sandi, dan informasi Akun Google lainnya. Anda dapat memperbarui informasi ini dan menyinkronkannya dengan database Anda sendiri, dan Anda mungkin memiliki tanggung jawab penuh atau sebagian atas siklus proses akun, bergantung pada solusi yang Anda tawarkan kepada pelanggan.
Skenario 2 menggambarkan situasi ini dengan lebih lengkap.
Untuk mengetahui informasi selengkapnya tentang penggunaan Directory API untuk mengelola informasi akun pengguna, lihat panduan developer Directory API: Akun Pengguna.
Skenario Akun Google
Beberapa skenario umum penyediaan identitas Akun Google dijelaskan di bagian berikut.
Skenario 1: Pelanggan bertanggung jawab atas siklus proses akun
Dalam skenario ini, pelanggan Anda membuat dan mengelola Akun Google untuk penggunanya.
Anda mendapatkan informasi akun pengguna dari direktori LDAP organisasi, dan Anda mengkorelasikannya dengan data Akun Google yang Anda dapatkan dari Google menggunakan Directory API Google.
Organisasi bertanggung jawab penuh atas siklus proses akun. Misalnya, saat Akun Google baru dibuat, organisasi menambahkan pengguna ke direktori LDAP mereka. Saat Anda menyinkronkan database ke direktori LDAP pada waktu berikutnya, database Anda akan menerima informasi tentang pengguna baru ini.
Dalam skenario ini:
- Anda hanya memiliki akses hanya baca ke Akun Google.
- Database Anda mendapatkan nama Akun Google, tetapi tidak mendapatkan nama pengguna atau sandi LDAP.
- Anda menggunakan Google Directory API untuk mendapatkan informasi akun dasar bagi pengguna pelanggan Anda. (Informasi yang tersedia untuk Anda adalah informasi
yang tidak dapat ditulis
yang ditampilkan oleh permintaan
Users.get). Anda menggunakan informasi ini untuk memverifikasi bahwa Akun Google pengguna ada sehingga pengguna dapat melakukan autentikasi ke perangkat mereka. - Pelanggan Anda menggunakan alat GCDS untuk melakukan sinkronisasi satu arah guna mengisi Akun Google pengguna. (Organisasi mungkin juga menggunakan GCDS untuk sinkronisasi berkelanjutan mereka sendiri setelah penyediaan identitas selesai.) Secara opsional, organisasi juga dapat menggunakan alat GSPS untuk menyinkronkan tidak hanya nama pengguna, tetapi juga sandi.
Skenario 2: EMM bertanggung jawab atas siklus proses akun
Dalam skenario ini, Anda menangani proses pembuatan Akun Google atas nama pelanggan, dan Anda bertanggung jawab atas siklus proses akun pengguna.
Misalnya, saat informasi pengguna berubah di direktori LDAP organisasi, Anda bertanggung jawab untuk memperbarui Akun Google pengguna tersebut. GCDS tidak digunakan dalam skenario ini.
Dalam skenario ini:
- Anda memiliki akses baca-tulis ke Akun Google.
- Database Anda mendapatkan nama Akun Google dan nama pengguna LDAP (dan secara opsional, hash sandi).
- Anda menggunakan Google Directory API atas nama pelanggan untuk membaca dan
menulis informasi akun pengguna organisasi. (Informasi yang tersedia untuk Anda adalah informasi yang tidak dapat ditulis
yang ditampilkan oleh permintaan
Users.get). Anda menggunakan informasi ini untuk memverifikasi bahwa Akun Google pengguna ada sehingga pengguna dapat melakukan autentikasi ke perangkat mereka. - Alat GCDS tidak digunakan.
Skenario autentikasi SSO berbasis SAML
Dalam deployment Akun Google, Anda atau pelanggan Anda dapat menggunakan Security Assertion Markup Language (SAML) dengan penyedia identitas (IdP) untuk mengautentikasi Akun Google yang terkait dengan setiap pengguna. Anda menggunakan nama Akun Google sebagai verifikasi bahwa Akun Google pengguna ada, yang diperlukan untuk autentikasi pengguna saat pengguna login ke perangkat mereka. Misalnya, SAML dapat digunakan dalam Skenario 2. Untuk mengetahui detail tentang cara menyiapkannya, lihat Menyiapkan Single Sign-On (SSO) untuk akun G Suite.