Jika Anda berencana menggabungkan Cloud Identity atau Google Workspace dengan penyedia identitas (IdP) eksternal, tetapi masih perlu mengonsolidasikan akun konsumen yang ada, dokumen ini membantu Anda memahami dan menilai interaksi antara sistem gabungan dan konsolidasi. Dokumen ini juga menunjukkan cara mengonfigurasikan sistem gabungan yang tidak mengganggu kemampuan Anda dalam mengonsolidasikan akun konsumen yang ada.
Interaksi antara sistem gabungan dan konsolidasi akun pengguna
Dalam penyiapan gabungan, Anda menghubungkan Cloud Identity atau Google Workspace ke sumber otoritatif eksternal sehingga sumber otoritatif tersebut dapat menyediakan akun pengguna secara otomatis di Cloud Identity atau Google Workspace.
Invarian ini biasanya disimpan untuk penyiapan gabungan:
- Sumber otoritatif adalah satu-satunya sumber identitas.
- Tidak ada akun pengguna di Cloud Identity atau Google Workspace selain akun yang disediakan oleh sumber otoritatif.
- Penyedia identitas SMAL tidak mengizinkan single sign-on Google untuk identitas apa pun selain akun pengguna yang disediakan oleh sumber otoritatif.
Meskipun invarian ini mencerminkan praktik terbaik untuk menggabungkan Google Cloud dengan penyedia identitas eksternal, invarian tersebut menyebabkan masalah saat Anda ingin memigrasikan akun konsumen yang ada:
- Akun konsumen yang ada tidak berasal dari sumber otoritatif. Akun konsumen ini sudah ada, dan sekarang harus ditautkan ke identitas yang dikenal oleh sumber resmi.
- Akun konsumen yang ada yang telah dimigrasikan ke Cloud Identity atau Google Workspace adalah akun pengguna yang belum disediakan oleh sumber otoritatif. Sumber otoritatif harus mengenali dan "mengadopsi" akun yang dimigrasikan ini.
- Identitas akun konsumen yang ada mungkin tidak dikenali oleh penyedia identitas SAML, tetapi masih harus diizinkan untuk menggunakan single sign-on.
Untuk mengizinkan konsolidasi akun konsumen yang sudah ada, Anda harus menyiapkan sistem gabungan sementara dengan cara yang aman untuk konsolidasi akun.
Membuat sistem gabungan aman untuk konsolidasi akun
Tabel berikut mencantumkan persyaratan yang perlu dipertimbangkan untuk memastikan sistem gabungan yang aman untuk konsolidasi akun. Jika berencana untuk menggunakan IdP eksternal tetapi masih perlu mengonsolidasikan akun konsumen yang ada, Anda harus memastikan bahwa penyiapan Anda memenuhi persyaratan ini sedari awal. Setelah menyelesaikan migrasi akun konsumen yang ada, Anda bebas mengubah konfigurasi karena persyaratan tersebut tidak berlaku lagi.
| Persyaratan | Justifikasi |
|---|---|
| Mengizinkan single sign-on untuk identitas dengan akun konsumen | Memigrasikan akun konsumen memerlukan transfer akun. Administrator
Cloud Identity atau Google Workspace memulai
transfer akun, tetapi pemilik akun konsumen harus memberikan izin
untuk menyelesaikan transfer tersebut. Sebagai administrator, Anda memiliki
kontrol terbatas atas kapan izin akan dinyatakan, serta kapan
transfer dilakukan.
Setelah pemilik menyatakan izin dan transfer selesai, semua proses login berikutnya akan dikenai single sign-on menggunakan IdP eksternal. Agar single sign-on berhasil, terlepas dari kapan transfer selesai, pastikan IdP eksternal Anda mengizinkan single sign-on untuk identitas semua akun konsumen yang ingin Anda migrasikan. |
| Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen | Jika Anda menyediakan akun pengguna untuk identitas yang sudah memiliki akun
konsumen, Anda akan membuat
akun bentrok. Akun bentrok mencegah Anda
mentransfer kepemilikan, konfigurasi dan
data akun konsumen apa pun yang terkait ke Cloud Identity atau Google Workspace.
Perilaku default dari banyak IdP eksternal adalah secara proaktif membuat akun pengguna di Cloud Identity atau Google Workspace. Perilaku ini dapat secara tidak sengaja menyebabkan pembuatan akun bentrok. Dengan mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen yang sudah ada, Anda dapat menghindari pembuatan akun bentrok secara tidak sengaja dan memastikan bahwa akun konsumen dapat ditransfer dengan benar. |
Jika Anda telah mengidentifikasi akun konsumen tanpa identitas yang cocok di IdP eksternal yang Anda anggap sah dan ingin dimigrasikan ke Cloud Identity atau Google Workspace, Anda harus memastikan bahwa konfigurasi federasi tidak mengganggu kemampuan Anda untuk memigrasikan akun konsumen ini.
| Persyaratan | Justifikasi |
|---|---|
| Mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal | Jika Anda memiliki akun pengguna di Cloud Identity atau
Google Workspace yang tidak memiliki identitas yang cocok di
IdP eksternal, IdP Anda mungkin menganggap akun pengguna tersebut berstatus tanpa induk dan
mungkin menangguhkan atau menghapusnya.
Dengan mencegah IdP eksternal menangguhkan atau menghapus akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal, Anda akan menghindari kehilangan konfigurasi dan data yang terkait dengan akun yang terpengaruh serta memastikan bahwa Anda dapat merekonsiliasi akun secara manual. |
Membuat sistem gabungan Microsoft Entra ID (sebelumnya Azure AD) aman untuk konsolidasi akun
Jika berencana menggabungkan Cloud Identity atau Google Workspace dengan Microsoft Entra ID (sebelumnya Azure AD), Anda dapat menggunakan aplikasi galeri Google Workspace.
Saat Anda mengaktifkan penyediaan, Microsoft Entra ID mengabaikan akun yang ada di Cloud Identity atau Google Workspace yang tidak memiliki padanan di Microsoft Entra ID, sehingga persyaratan untuk mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal akan selalu terpenuhi.
Bergantung pada cara mengonfigurasi aplikasi galeri, Anda tetap harus memastikan bahwa Anda melakukan hal berikut:
- Mengizinkan single sign-on untuk identitas dengan akun konsumen.
- Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Ada beberapa cara untuk memenuhi persyaratan ini. Setiap pendekatan memiliki kelebihan dan kekurangan.
Pendekatan 1: Jangan mengonfigurasi penyediaan
Dalam pendekatan ini, Anda mengonfigurasi aplikasi galeri untuk menangani single sign-on, tetapi jangan mengonfigurasi penyediaan pengguna otomatis. Dengan tidak mengonfigurasi penyediaan pengguna, Anda mencegah penyediaan pengguna otomatis dengan akun konsumen.
Untuk mengizinkan single sign-on untuk identitas dengan akun konsumen, tetapkan aplikasi ke semua identitas yang mungkin pada akhirnya memerlukan akses ke layanan Google, meskipun akun konsumen mereka yang sudah ada masih akan dimigrasikan.
Untuk pengguna yang memiliki akun konsumen yang sudah ada, akun pengguna Cloud Identity atau Google Workspace yang sesuai akan otomatis dibuat saat permintaan transfer diterima. Kemudian, pengguna tersebut dapat langsung menggunakan single sign-on.
Untuk pengguna yang tidak memiliki akun pengguna di Cloud Identity atau Google Workspace, Anda harus membuatnya secara manual.
Meskipun memenuhi persyaratan dan paling tidak rumit untuk disiapkan, pendekatan ini memiliki batasan dalam hal perubahan atribut apa pun atau penangguhan pengguna yang dilakukan di Microsoft Entra ID tidak akan diterapkan ke Cloud Identity atau Google Workspace.
Pendekatan 2: Dua aplikasi dengan penetapan manual
Dengan pendekatan ini, Anda mengatasi batasan untuk membuat akun pengguna secara manual di Google Workspace atau Cloud Identity untuk pengguna yang tidak memiliki akun. Idenya adalah menggunakan dua aplikasi galeri, masing-masing untuk penyediaan dan single sign-on:
- Aplikasi pertama digunakan secara eksklusif untuk menyediakan pengguna dan grup, serta menonaktifkan single sign-on. Dengan menetapkan pengguna ke aplikasi ini, Anda memiliki kontrol atas akun yang disediakan ke Cloud Identity atau Google Workspace.
- Aplikasi kedua digunakan secara eksklusif untuk single sign-on dan tidak diotorisasi untuk menyediakan pengguna. Dengan menetapkan pengguna ke aplikasi ini, Anda memiliki kontrol atas pengguna mana yang diizinkan untuk login.
Dengan menggunakan kedua aplikasi ini, tetapkan pengguna sebagai berikut:
- Tetapkan semua identitas yang pada akhirnya memerlukan akses ke layanan Google ke aplikasi single sign-on. Sertakan identitas dengan akun konsumen yang ada sehingga Anda mengizinkan single sign-on untuk identitas dengan akun konsumen.
- Saat menetapkan identitas ke aplikasi penyediaan, sertakan identitas yang pada akhirnya memerlukan akses ke layanan Google, tetapi buat pengecualian untuk semua identitas yang diketahui memiliki akun konsumen yang sudah ada. Dengan cara ini, Anda mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Pendekatan 3: Dua aplikasi dengan pembuatan pengguna dinonaktifkan
Saat mengonfigurasi penyediaan, Anda perlu melakukan otorisasi pada Microsoft Entra ID untuk mengakses Cloud Identity atau Google Workspace menggunakan akun Cloud Identity atau Google Workspace. Biasanya, lebih baik gunakan akun admin super khusus untuk tujuan ini karena akun admin super dikecualikan dari single sign-on (artinya, konfigurasi SSO tidak berlaku untuk akun tersebut; mereka akan terus menggunakan sandi untuk masuk).
Namun, untuk skenario ini, Anda dapat membuat Microsoft Entra ID menggunakan akun yang lebih dibatasi untuk migrasi yang tidak mengizinkan Microsoft Entra ID membuat pengguna. Dengan begitu, Anda secara efektif mencegah Azure menyediakan akun pengguna secara otomatis untuk identitas dengan akun konsumen, terlepas dari pengguna yang ditetapkan ke aplikasi penyediaan.
Akun pengguna administrator yang dibatasi di Cloud Identity atau Google Workspace hanya boleh memiliki hak istimewa berikut:
- Unit Organisasi > Baca
- Pengguna > Baca
- Pengguna > Update
- Grup
Kelemahan dari pendekatan ini adalah untuk pengguna tanpa akun yang tidak dikelola, Anda harus membuat akun secara manual di Cloud Identity atau Google Workspace.
Menggabungkan dengan Microsoft Entra ID: Perbandingan
Tabel berikut merangkum pendekatan-pendekatan tersebut.
| Mengizinkan single sign-on untuk identitas dengan akun konsumen | Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen | Mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal | Penyediaan akun baru secara otomatis | Update akun yang dimigrasikan secara otomatis | |
|---|---|---|---|---|---|
| Pendekatan 1: Tidak ada penyediaan | ✅ | ✅ | ✅ | X | X |
| Pendekatan 2: Dua aplikasi dengan penetapan manual | ✅ | Rentan terhadap error manual | ✅ | ✅ | ✅ |
| Pendekatan 3: Dua aplikasi dengan pembuatan pengguna dinonaktifkan | ✅ | ✅ | ✅ | X | ✅ |
Membuat sistem gabungan Active Directory aman untuk akun
Jika berencana untuk menggabungkan Cloud Identity atau Google Workspace dengan Active Directory, Anda dapat menggunakan Google Cloud Directory Sync (GCDS) dan Active Directory Federation Services (AD FS). Saat mengonfigurasi GCDS dan AD FS, pastikan Anda melakukan hal berikut:
- Mengizinkan single sign-on untuk identitas dengan akun konsumen.
- Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
- Mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal.
Ada beberapa cara untuk memenuhi persyaratan ini. Setiap pendekatan memiliki kelebihan dan kekurangan.
Pendekatan 1: Menonaktifkan GCDS
Dalam pendekatan ini, Anda menyiapkan single sign-on dengan AD FS, tetapi tidak mengaktifkan GCDS hingga Anda selesai memigrasikan akun pengguna yang tidak dikelola. Dengan menonaktifkan GCDS, Anda mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Untuk mengizinkan single sign-on untuk identitas dengan akun konsumen, buat kebijakan akses kontrol kustom di AD FS dan tetapkan semua identitas yang mungkin pada akhirnya memerlukan akses ke layanan Google, meskipun akun konsumen mereka yang ada masih akan dimigrasikan.
Untuk pengguna yang memiliki akun konsumen yang sudah ada, akun pengguna Cloud Identity atau Google Workspace yang sesuai akan otomatis dibuat saat permintaan transfer diterima. Dengan menggunakan kebijakan kontrol akses khusus, Anda memastikan bahwa pengguna dapat langsung menggunakan single sign-on.
Untuk pengguna yang tidak memiliki akun pengguna di Cloud Identity atau Google Workspace, Anda harus membuatnya secara manual.
Meskipun memenuhi persyaratan dan paling tidak rumit untuk disiapkan, pendekatan ini memiliki batasan, yaitu perubahan atribut atau penangguhan pengguna yang dilakukan di Active Directory tidak akan diterapkan di Cloud Identity atau Google Workspace.
Pendekatan 2: GCDS dengan penetapan manual
Dalam pendekatan ini, Anda mengatasi batasan untuk membuat akun pengguna secara manual di Cloud Identity di Google Workspace untuk pengguna yang belum memiliki akun:
Setara dengan Pendekatan 1, Anda mengizinkan single sign-on untuk identitas dengan akun konsumen dengan membuat kebijakan kontrol akses kustom di AD FS dan menetapkan semua identitas yang mungkin pada akhirnya memerlukan akses ke layanan Google, meskipun akun konsumen mereka yang ada masih akan dimigrasikan.
Buat grup di Active Directory yang menunjukkan akun pengguna yang ingin Anda sediakan secara otomatis ke GCDS. Dalam daftar anggota, sertakan identitas yang pada akhirnya memerlukan akses ke layanan Google, tetapi kecualikan semua identitas yang diketahui memiliki akun konsumen yang sudah ada.
Konfigurasikan GCDS agar menyediakan akun pengguna hanya untuk identitas yang merupakan anggota grup ini. Dengan cara ini, Anda mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Batasan utama pendekatan ini adalah Anda tidak dapat mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal. Oleh karena itu, pendekatan ini hanya berlaku jika Anda tidak memiliki akun konsumen tanpa identitas yang cocok di IdP eksternal.
Pendekatan 3: Melarang GCDS untuk membuat pengguna
Saat mengonfigurasi penyediaan, Anda harus memberikan otorisasi kepada GCDS untuk mengakses Cloud Identity atau Google Workspace. Biasanya, lebih baik gunakan akun admin super khusus untuk tujuan ini, karena akun tersebut dikecualikan dari single sign-on (yaitu, konfigurasi SSO apa pun tidak berlaku untuk akun tersebut; akun akan terus menggunakan sandi untuk login).
Namun, untuk skenario ini, Anda dapat membuat GCDS menggunakan akun yang lebih dibatasi untuk migrasi dan tidak mengizinkan pembuatan pengguna. Dengan begitu, Anda secara efektif mencegah GCDS menyediakan akun pengguna untuk identitas dengan akun konsumen secara otomatis dan menghapus akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal.
Akun pengguna administrator yang dibatasi di Cloud Identity atau Google Workspace hanya boleh memiliki hak istimewa berikut:
- Unit Organisasi
- Pengguna > Baca
- Pengguna > Update
- Grup
- Pengelolaan Skema
- Pengelolaan Domain
Kelemahan dari pendekatan ini adalah untuk pengguna tanpa akun yang tidak dikelola, Anda harus membuat akun secara manual di Cloud Identity atau Google Workspace.
Penggabungan dengan Active Directory: Perbandingan
Tabel berikut merangkum pendekatan-pendekatan tersebut.
| Mengizinkan single sign-on untuk identitas dengan akun konsumen | Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen | Mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal | Penyediaan akun baru secara otomatis | Update akun yang dimigrasikan secara otomatis | |
|---|---|---|---|---|---|
| Pendekatan 1: Jangan mengonfigurasi penyediaan | ✅ | ✅ | ✅ | X | X |
| Pendekatan 2: GCDS dengan penetapan manual | ✅ | Rentan terhadap error manual | X | ✅ | ✅ |
| Pendekatan 3: Melarang GCDS untuk membuat pengguna | ✅ | ✅ | ✅ | X | ✅ |
Membuat sistem gabungan Okta aman untuk konsolidasi akun
Untuk menggabungkan Cloud Identity atau Google Workspace dengan Okta, Anda dapat menggunakan aplikasi Google Workspace dari katalog aplikasi Okta. Aplikasi ini dapat menangani single sign-on dan menyediakan pengguna dan grup ke Cloud Identity atau Google Workspace.
Saat Anda menggunakan aplikasi Google Workspace untuk penyediaan, Okta mengabaikan pengguna yang sudah ada di Cloud Identity atau Google Workspace yang tidak memiliki padanan di Okta, sehingga persyaratan untuk mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal akan selalu terpenuhi.
Bergantung pada cara mengonfigurasi Okta, Anda tetap harus melakukan hal berikut:
- Mengizinkan single sign-on untuk identitas dengan akun konsumen.
- Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Ada beberapa cara untuk memenuhi persyaratan ini. Setiap pendekatan memiliki kelebihan dan kekurangan.
Pendekatan 1: Jangan mengonfigurasi penyediaan
Dalam pendekatan ini, Anda mengonfigurasi aplikasi Google Workspace untuk menangani single sign-on, tetapi jangan mengonfigurasi penyediaan sama sekali. Dengan tidak mengonfigurasi penyediaan pengguna, Anda mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Untuk mengizinkan single sign-on untuk identitas dengan akun konsumen, tetapkan aplikasi ke semua identitas yang mungkin pada akhirnya memerlukan akses ke layanan Google, meskipun akun konsumen mereka yang sudah ada masih akan dimigrasikan. Ikon Google Workspace atau Google Cloud muncul di halaman beranda Okta yang berisi semua identitas yang telah ditetapkan ke aplikasi. Namun, login akan gagal kecuali akun pengguna yang sesuai ada di sisi Google.
Untuk pengguna yang memiliki akun konsumen yang sudah ada, akun pengguna Cloud Identity atau Google Workspace yang sesuai akan otomatis dibuat saat permintaan transfer diterima. Kemudian, pengguna tersebut dapat langsung menggunakan single sign-on.
Meskipun memenuhi persyaratan dan paling tidak rumit untuk disiapkan, pendekatan ini memiliki batasan, yaitu perubahan atribut atau penangguhan pengguna yang dilakukan di Okta tidak akan diterapkan ke Cloud Identity atau Google Workspace. Kelemahan lain dari pendekatan ini adalah Anda harus membuat akun secara manual di Cloud Identity atau Google Workspace untuk semua pengguna yang belum memiliki akun konsumen.
Pendekatan 2: Penyediaan dengan penetapan manual
Dalam pendekatan ini, Anda mengonfigurasi aplikasi Google Workspace untuk menangani single sign-on dan penyediaan, tetapi hanya mengaktifkan fitur penyediaan berikut:
- Buat pengguna
- Perbarui atribut pengguna
- Nonaktifkan pengguna
Saat menetapkan identitas ke aplikasi, sertakan identitas yang pada akhirnya memerlukan akses ke layanan Google, tetapi kecualikan semua identitas yang diketahui memiliki akun konsumen yang sudah ada. Dengan cara ini, Anda mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Segera setelah pengguna menyetujui permintaan transfer, tetapkan pengguna ke aplikasi sehingga dapat menggunakan single sign-on dan mengakses Google Workspace atau Google Cloud.
Satu kelemahan dari pendekatan ini adalah bahwa setiap kesalahan yang Anda buat saat penetapan dapat langsung menyebabkan akun bentrok dibuat, sehingga pendekatan ini jauh lebih berisiko daripada beberapa pendekatan lainnya.
Kelemahan lain dari pendekatan ini adalah akun yang dimigrasikan akan terkunci untuk sementara waktu. Setelah menerima permintaan transfer, pengguna harus melakukan login berikutnya melalui Okta. Upaya login ini akan gagal sampai Anda menetapkan pengguna ke aplikasi di Okta.
Pendekatan 3: Penyediaan dengan pembuatan pengguna dinonaktifkan
Dalam pendekatan ini, Anda mengonfigurasi Google Workspace untuk menangani single sign-on dan penyediaan, tetapi hanya aktifkan fitur penyediaan berikut:
- Perbarui atribut pengguna
- Nonaktifkan pengguna
Biarkan opsi Create Users dinonaktifkan dan tetapkan semua identitas yang pada akhirnya memerlukan akses ke layanan Google ke aplikasi. Sertakan identitas dengan akun konsumen yang ada sehingga Anda mengizinkan single sign-on untuk identitas dengan akun konsumen.
Dengan melarang Okta membuat akun, Anda mencegah Okta menyediakan akun pengguna untuk identitas dengan akun konsumen secara otomatis. Pada saat yang sama, konfigurasi ini tetap memungkinkan Okta menetapkan perubahan atribut dan penangguhan pengguna ke Cloud Identity atau Google Workspace untuk pengguna yang memiliki Akun Google yang sesuai.
Untuk identitas yang tidak memiliki akun pengguna yang sesuai di Cloud Identity atau Google Workspace, Okta mungkin menampilkan pesan error di konsol Admin Okta:
Untuk pengguna yang memiliki akun konsumen yang sudah ada, akun pengguna Cloud Identity atau Google Workspace yang sesuai akan otomatis dibuat saat permintaan transfer diterima. Kemudian, pengguna tersebut dapat langsung menggunakan single sign-on. Meskipun akun pengguna sudah berfungsi pada tahap ini, Okta mungkin belum menampilkan ikon di halaman beranda pengguna dan mungkin akan terus menampilkan pesan error di UI Admin. Untuk memperbaikinya, coba lagi tugas penetapan di Dasbor Administrator Okta.
Pendekatan ini berhasil mencegah Okta menyediakan akun pengguna secara otomatis untuk identitas dengan akun konsumen, tetapi masih mengizinkan single sign-on untuk identitas dengan akun konsumen. Pendekatan ini juga tidak terlalu rentan terhadap kesalahan konfigurasi yang tidak disengaja dibandingkan dengan pendekatan kedua. Satu kelemahannya adalah untuk pengguna tanpa akun konsumen yang ada, Anda harus membuat akun pengguna di Cloud Identity atau Google Workspace secara manual.
Pendekatan 4: Dua aplikasi dengan penetapan manual
Anda dapat mengatasi beberapa kekurangan pendekatan sebelumnya menggunakan dua aplikasi, masing-masing untuk penyediaan dan untuk single sign-on:
- Konfigurasikan satu instance aplikasi Google Workspace agar hanya menangani penyediaan saja. Fungsi single sign-on aplikasi tidak digunakan. Dengan menetapkan pengguna ke aplikasi ini, Anda memiliki kontrol atas akun mana yang disediakan ke Cloud Identity ke Google Workspace. Anda dapat memastikan bahwa aplikasi ini disembunyikan secara efektif dari pengguna dengan mengaktifkan opsi Jangan tampilkan ikon aplikasi ke pengguna.
- Konfigurasikan instance lain dari aplikasi Google Workspace untuk tujuan single sign-on saja. Dengan menetapkan pengguna ke aplikasi ini, Anda memiliki kontrol atas akun mana yang diizinkan untuk login.
Dengan menggunakan kedua aplikasi ini, tetapkan pengguna sebagai berikut:
- Tetapkan semua identitas yang pada akhirnya memerlukan akses ke layanan Google ke aplikasi single sign-on. Sertakan identitas dengan akun konsumen yang ada sehingga Anda mengizinkan single sign-on untuk identitas dengan akun konsumen.
Saat menetapkan identitas ke aplikasi penyediaan, sertakan identitas yang pada akhirnya memerlukan akses ke layanan Google, tetapi buat pengecualian untuk semua identitas yang diketahui memiliki akun konsumen yang sudah ada. Dengan cara ini, Anda mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen.
Setiap kali pengguna menyetujui permintaan transfer, tetapkan pengguna tersebut ke aplikasi.
Menggabungkan dengan Okta: Perbandingan
Tabel berikut merangkum pendekatan-pendekatan tersebut.
| Mengizinkan single sign-on untuk identitas dengan akun konsumen | Mencegah penyediaan pengguna otomatis untuk identitas dengan akun konsumen | Mencegah penghapusan akun yang dimigrasikan tanpa identitas yang cocok di IdP eksternal | Penyediaan akun baru secara otomatis | Update akun yang dimigrasikan secara otomatis | |
|---|---|---|---|---|---|
| Pendekatan 1: Tidak ada penyediaan | ✅ | ✅ | ✅ | X | X |
| Pendekatan 2: Penyediaan dengan penetapan manual | X | Berisiko | ✅ | ✅ | ✅ |
| Pendekatan 3: Penyediaan dengan pembuatan pengguna dinonaktifkan | ✅ | ✅ | ✅ | X | ✅ |
| Pendekatan 4: Dua aplikasi dengan penetapan manual | ✅ | Berisiko | ✅ | ✅ | ✅ |
Langkah selanjutnya
- Tinjau cara untuk dapat menyiapkan sistem gabungan dengan Active Directory atau Microsoft Entra ID.
- Mulai proses orientasi Anda dengan menyiapkan akun Cloud Identity atau Google Workspace.