Artikel ini memberikan informasi tambahan tentang penggunaan identitas eksternal dengan Identity-Aware Proxy (IAP) dan bukan Akun Google.
Ringkasan
IAP mengontrol akses ke aplikasi dan resource Anda. IAP memanfaatkan identitas pengguna dan konteks permintaan untuk menentukan apakah pengguna harus diizinkan mengakses atau tidak. IAP adalah komponen penyusun Chrome Enterprise Premium, sebuah solusi keamanan perusahaan yang memungkinkan karyawan bekerja dari jaringan yang tidak tepercaya tanpa menggunakan VPN.
Secara default, IAP menggunakan identitas Google dan IAM. Dengan memanfaatkan Identity Platform, Anda dapat mengautentikasi pengguna dengan berbagai penyedia identitas eksternal, seperti:
- Email/sandi
- OAuth (Google, Facebook, Twitter, GitHub, Microsoft, dll.)
- SAML
- OIDC
- Nomor telepon
- Kustom
- Anonim
Hal ini berguna jika aplikasi Anda sudah menggunakan sistem autentikasi eksternal, dan memigrasikan pengguna Anda ke Akun Google tidak praktis.
Multi-tenancy
Multi-tenancy Identity Platform awalnya dirancang untuk skenario B2B, di mana satu perusahaan menjual layanan ke perusahaan lain. Dalam kasus ini, developer biasanya ingin memisahkan populasi pengguna ke dalam kumpulan terisolasi. Silo ini disebut sebagai tenant.
Pertimbangkan diagram hubungan fiktif di bawah:
Dalam contoh ini, Acme adalah produsen mobil (agen) yang menggunakan Identity Platform untuk menyediakan layanan bagi dealer (tenant). Dealer ini pada gilirannya menyediakan layanan kepada pelanggan, karyawan, dan kontraktor mereka. Meskipun produsen memiliki layanan, setiap dealer dapat menggunakan serangkaian penyedia identitasnya sendiri untuk autentikasi. Sesi dan data pengguna dicakup berdasarkan per-tenant, jadi jika pengguna memiliki hubungan dengan beberapa dealer, setiap hubungan akan ditangani secara terpisah.
Bergantung pada kasus penggunaan, ada beberapa cara untuk menyusun hierarki tenant.
Tidak ada tenant
Anda hanya memerlukan multi-tenancy jika perlu mengisolasi resource. Tidak semua aplikasi memiliki persyaratan ini. Misalnya, jika Anda memiliki satu aplikasi App Engine dan ingin memblokir akses semua pengguna di luar jaringan Anda, tidak perlu ada multi-tenancy. Secara default, Identity Platform menyimpan dan mengautentikasi pengguna berdasarkan per project, sehingga tidak diperlukan konfigurasi tambahan dalam kasus ini.
Contoh lainnya adalah konglomerat dengan beberapa anak perusahaan. Meskipun setiap anak perusahaan memiliki sistem autentikasi terkelola sendiri (menggunakan OIDC atau SAML), semua karyawan mungkin berbagi manfaat tingkat tinggi yang sama, seperti layanan kesehatan, cuti, dan penggajian. Dalam hal ini, autentikasi di tingkat project sudah cukup.
Satu tenant per resource
Secara default, token Identity Platform non-tenant berlaku di tingkat project. Secara teoretis, ini berarti pengguna dapat mengautentikasi dengan satu resource IAP, lalu menggunakan token untuk mengakses layanan lain dalam project yang sama. Hal ini merupakan risiko keamanan.
Untuk mencegah kebocoran token, pisahkan setiap IAP dengan menetapkan tenantnya masing-masing. Token yang dibuat dalam konteks khusus tenant hanya valid untuk tenant tertentu tersebut. Jika pengguna mencoba mengakses resource IAP lain yang menggunakan tenant berbeda, mereka akan diminta untuk melakukan autentikasi lagi.
Beberapa tenant per resource
Satu resource IAP dapat memiliki beberapa tenant yang terkait dengannya.
Saat pengguna mengakses resource, Anda memiliki beberapa opsi untuk menentukan tenant yang akan digunakan. Misalnya, Anda dapat meminta pengguna untuk memasukkan emailnya terlebih dahulu, lalu menemukan secara terprogram tenant yang cocok dengan domain email tersebut. Atau, Anda dapat menampilkan UI yang mencantumkan semua tenant yang valid, dan meminta pengguna untuk memilih salah satunya.
Pengguna dapat tergabung dalam beberapa tenant dengan berbagai tingkat akses. Meskipun Anda tidak dapat menggunakan IAM untuk mengelola kontrol akses dengan identitas eksternal, Token Web JSON yang dihasilkan oleh IAP membawa klaim dari token ID Identity Platform, dan aplikasi dapat memfilter akses berdasarkan klaim ini.
Contoh skenario multi-tenancy adalah perusahaan manfaat karyawan yang memiliki banyak pelanggan yang berbagi satu portal web. Saat pengguna membuka portal, mereka akan memilih perusahaan mereka (penyewa) terlebih dahulu, lalu melakukan autentikasi dengan penyedia apa pun yang digunakan perusahaan mereka dengan kredensial perusahaan mereka.