Artikel ini memberikan informasi tambahan tentang penggunaan identitas eksternal dengan Identity-Aware Proxy (IAP), 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. IAP adalah elemen penyusun Chrome Enterprise Premium, 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 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 yang terisolasi. Silo ini disebut sebagai tenant.
Perhatikan diagram hubungan fiktif di bawah:
Dalam contoh ini, Acme adalah produsen mobil (agen) yang menggunakan Identity Platform untuk menyediakan layanan kepada dealer (tenant). Dealer ini pada gilirannya memberikan layanan kepada pelanggan, karyawan, dan kontraktor mereka. Meskipun produsen memiliki layanan tersebut, setiap dealer dapat menggunakan kumpulan penyedia identitasnya sendiri untuk autentikasi. Sesi dan data pengguna dicakup berdasarkan per tenant, sehingga jika pengguna memiliki hubungan dengan beberapa dealer, masing-masing akan ditangani secara independen.
Bergantung pada kasus penggunaan Anda, ada sejumlah 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 ke semua pengguna di luar jaringan Anda, Anda tidak memerlukan multi-tenancy. Secara default, Identity Platform menyimpan dan mengautentikasi pengguna 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 memiliki manfaat tingkat tinggi yang sama, seperti layanan kesehatan, liburan, dan penggajian. Dalam hal ini, autentikasi di level project sudah cukup.
Satu tenant per resource
Secara default, token Identity Platform non-tenant valid di level project. Secara teoritis, ini berarti pengguna dapat melakukan autentikasi dengan satu resource IAP, lalu menggunakan token untuk mengakses layanan lain dalam project yang sama. Hal ini menimbulkan risiko keamanan.
Untuk mencegah kebocoran token, isolasi setiap IAP dengan menetapkan tenant-nya masing-masing. 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 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 secara terprogram menemukan 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 tunjangan karyawan yang memiliki banyak pelanggan yang berbagi satu portal web. Saat mengunjungi portal, pengguna akan memilih perusahaan (tenant) terlebih dahulu, lalu melakukan autentikasi dengan penyedia apa pun yang digunakan perusahaan mereka dengan kredensial perusahaan.