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 untuk mengakses. IAP adalah komponen penyusun BeyondCorp, sebuah model 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, dengan satu perusahaan menjual layanan kepada perusahaan lain. Dalam kasus ini, developer biasanya ingin memisahkan populasi pengguna ke dalam kumpulan terpisah. Silo ini disebut sebagai tenants.
Pertimbangkan diagram hubungan fiktif di bawah ini:
Dalam contoh ini, Acme adalah produsen mobil (agen) yang menggunakan Identity Platform untuk menyediakan layanan kepada dealer (penyewa). Dealer ini pada gilirannya 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 dan data pengguna dibatasi berdasarkan per-tenant, sehingga jika pengguna memiliki hubungan dengan beberapa dealer, setiap hubungan akan ditangani secara independen.
Bergantung pada kasus penggunaan, 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 tidak memerlukan multi-tenancy. Secara default, Identity Platform menyimpan dan mengautentikasi pengguna berdasarkan per project, sehingga tidak ada konfigurasi tambahan yang diperlukan dalam hal ini.
Contoh lainnya adalah konglomerasi dengan beberapa anak perusahaan. Meskipun setiap anak perusahaan memiliki sistem autentikasi terkelolanya sendiri (menggunakan OIDC atau SAML), semua karyawan mungkin memiliki manfaat tingkat tinggi yang sama, seperti layanan kesehatan, liburan, dan gaji. Dalam hal ini, autentikasi di tingkat project sudah memadai.
Satu tenant per resource
Secara default, token Identity Platform non-tenant valid di level project. Secara teoritis, 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, isolasi setiap IAP dengan menetapkan setiap tenantnya sendiri. Token yang dibuat dalam konteks khusus tenant hanya valid untuk tenant tersebut. Jika pengguna mencoba mengakses resource IAP lain yang menggunakan tenant yang 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 email mereka 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 tergabung dalam beberapa tenant dengan tingkat akses yang bervariasi. 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 menggunakan satu portal web. Saat pengguna mengunjungi portal, mereka akan memilih perusahaan (tenant) terlebih dahulu, lalu melakukan autentikasi dengan penyedia apa pun yang digunakan oleh perusahaan mereka dengan kredensial perusahaan mereka.