Artikel ini memberikan informasi tambahan tentang penggunaan identitas eksternal dengan Identity-Aware Proxy (IAP), bukan Akun Google.
Ringkasan
IAP mengontrol akses ke aplikasi App Engine dan VM Compute Engine Anda yang berjalan di Google Cloud. Cara ini memanfaatkan identitas pengguna dan konteks permintaan untuk menentukan apakah pengguna harus diberi izin untuk mengaksesnya. IAP adalah elemen penyusun BeyondCorp, model keamanan perusahaan yang memungkinkan karyawan bekerja dari jaringan yang tidak tepercaya tanpa menggunakan VPN.
Secara default, IAP menggunakan identitas dan IAM Google. 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
- Khusus
- Anonim
Hal ini berguna jika aplikasi Anda sudah menggunakan sistem autentikasi eksternal, dan proses migrasi pengguna ke Akun Google tidaklah praktis.
Multi-tenancy
Multi-tenancy Identity Platform awalnya dirancang untuk skenario B2B, ketika satu perusahaan menjual layanan ke perusahaan lain. Dalam hal ini, developer biasanya ingin memisahkan populasi pengguna ke dalam kumpulan yang terisolasi. Silo ini disebut sebagai tenant.
Pertimbangkan diagram hubungan fiktif di bawah ini:
Dalam contoh ini, Acme adalah produsen mobil (agen) yang menggunakan Identity Platform untuk memberikan layanan ke dealer (penyewa). Dealer ini kemudian memberikan layanan kepada pelanggan, karyawan, dan kontraktor mereka. Meskipun produsen memiliki layanan tersebut, setiap dealer dapat menggunakan kumpulan penyedia identitas mereka sendiri untuk autentikasi. Sesi pengguna dan data dicakup per tenant, sehingga jika pengguna memiliki hubungan dengan beberapa dealer, masing-masing dealer akan ditangani secara terpisah.
Bergantung pada kasus penggunaan Anda, ada sejumlah cara untuk menyusun hierarki tenant.
Tidak ada penyewa
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 ke semua pengguna di luar jaringan, multi-tenancy tidak diperlukan. Secara default, Identity Platform menyimpan dan mengautentikasi pengguna per project, sehingga konfigurasi tambahan tidak diperlukan 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 dapat berbagi manfaat tingkat tinggi yang sama, seperti layanan kesehatan, liburan, dan penggajian. Dalam hal ini, otentikasi pada tingkat proyek sudah cukup.
Satu tenant per resource
Secara default, token Identity Platform non-tenant valid di level project. Secara teoretis, hal ini berarti pengguna dapat melakukan autentikasi dengan satu resource IAP, lalu menggunakan token untuk mengakses layanan lain dalam project yang sama. Ini adalah risiko keamanan.
Untuk mencegah kebocoran token, isolasi setiap IAP dengan menetapkan masing-masing tenantnya sendiri. Token yang dibuat dalam konteks khusus tenant hanya valid untuk tenant tersebut. Jika pengguna mencoba mengakses resource IAP lain yang menggunakan tenant berbeda, mereka akan diminta untuk mengautentikasi 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 secara terprogram menemukan tenant yang cocok dengan domain email. Atau, Anda dapat menampilkan UI yang mencantumkan semua tenant yang valid, dan meminta pengguna untuk memilih salah satunya.
Pengguna dapat menjadi bagian dari beberapa tenant dengan berbagai tingkat akses. Meskipun Anda tidak dapat menggunakan IAM untuk mengelola kontrol akses dengan identitas eksternal, Token Web JSON yang dibuat oleh IAP membawa klaim dari token ID Identity Platform, dan aplikasi dapat memfilter akses berdasarkan klaim ini.
Contoh skenario multi-tenancy adalah perusahaan tunjangan karyawan yang memiliki banyak pelanggan yang berbagi satu portal web. Saat pengguna mengunjungi portal, pertama-tama mereka memilih perusahaan (penyewa), lalu mengautentikasi dengan penyedia apa pun yang digunakan oleh perusahaan mereka dengan kredensial perusahaan mereka.