Pola Identitas Federasi

Delegasikan autentikasi ke IdP eksternal. Hal ini dapat menyederhanakan pengembangan, meminimalkan persyaratan administrasi pengguna, dan meningkatkan pengalaman pengguna aplikasi.

Konteks dan masalah

Pengguna biasanya perlu menggunakan beberapa aplikasi yang disediakan dan dihosting oleh organisasi berbeda yang memiliki hubungan bisnis dengan mereka. Pengguna ini mungkin diminta untuk menggunakan informasi masuk tertentu (dan berbeda) untuk masing-masing pengguna. Hal ini bisa:

• Menyebabkan pengalaman pengguna terputus-putus. Pengguna sering lupa informasi masuk ketika mereka memiliki banyak informasi masuk yang berbeda.

• Mengungkapkan kerentanan keamanan. Saat pengguna meninggalkan perusahaan, akun harus segera dicabut aksesnya. Sangat mudah untuk mengabaikan hal ini dalam organisasi besar.

• Mempersulit manajemen pengguna. Administrator harus mengelola informasi masuk untuk semua pengguna, dan melakukan tugas tambahan seperti memberikan pengingat kata sandi.

Pengguna biasanya lebih suka menggunakan informasi masuk yang sama untuk semua aplikasi ini.

Solusi

Menerapkan mekanisme autentikasi yang dapat menggunakan identitas federasi. Pisahkan autentikasi pengguna dari kode aplikasi, dan delegasikan autentikasi ke IdP tepercaya. Hal ini dapat menyederhanakan pengembangan dan memungkinkan pengguna mengautentikasi menggunakan jangkauan yang lebih luas dari penyedia identitas (IdP) sambil meminimalkan biaya administrasi. Anda juga dapat memisahkan autentikasi dari otorisasi dengan jelas.

IdP tepercaya mencakup direktori perusahaan, layanan federasi lokal, layanan token keamanan (STS) lainnya yang disediakan oleh mitra bisnis, atau IdP sosial yang dapat mengautentikasi pengguna yang memiliki, misalnya, akun Microsoft, Google, Yahoo!, atau Facebook.

Gambar tersebut mengilustrasikan pola Identitas Federasi ketika aplikasi klien perlu mengakses layanan yang memerlukan autentikasi. Autentikasi dilakukan oleh IdP yang bekerja bersama dengan STS. IdP mengeluarkan token keamanan yang memberikan informasi tentang pengguna yang diautentikasi. Informasi ini, yang disebut sebagai klaim, mencakup identitas pengguna, dan mungkin juga mencakup informasi lain seperti keanggotaan peran dan hak akses yang lebih terperinci.

Model ini sering disebut sebagai kontrol akses berbasis klaim. Aplikasi dan layanan mengotorisasi akses ke fitur dan fungsi berdasarkan klaim yang terkandung dalam token. Layanan yang memerlukan autentikasi harus memercayai IdP. Aplikasi klien menghubungi IdP yang melakukan autentikasi. Jika autentikasi berhasil, IdP mengembalikan token yang berisi klaim yang mengidentifikasi pengguna ke STS (perhatikan bahwa IdP dan STS dapat menjadi layanan yang sama). STS dapat mengubah dan menambah klaim dalam token berdasarkan aturan yang telah ditentukan, sebelum mengembalikannya ke klien. Aplikasi klien kemudian dapat meneruskan token ini ke layanan sebagai bukti identitasnya.

Mungkin ada layanan token keamanan tambahan dalam rantai kepercayaan. Misalnya, dalam skenario yang dijelaskan nanti, STS lokal mempercayai STS lain yang bertanggung jawab untuk mengakses IdP untuk mengautentikasi pengguna. Pendekatan ini umum dalam skenario perusahaan di mana ada STS dan direktori lokal.

Autentikasi terfederasi memberikan solusi berbasis standar untuk masalah kepercayaan identitas di berbagai domain, dan dapat mendukung akses menyeluruh. Jenis autentikasi ini menjadi lebih umum di semua jenis aplikasi, terutama aplikasi yang dihosting cloud, karena mendukung akses menyeluruh tanpa memerlukan koneksi jaringan langsung ke penyedia identitas. Pengguna tidak harus memasukkan informasi masuk untuk setiap aplikasi. Hal ini meningkatkan keamanan karena mencegah pembuatan informasi masuk yang diperlukan untuk mengakses banyak aplikasi berbeda, dan juga menyembunyikan informasi masuk pengguna dari semua kecuali IdP asli. Aplikasi hanya melihat informasi identitas terautentikasi yang terkandung di dalam token.

Identitas terfederasi juga memiliki keuntungan utama bahwa pengelolaan identitas dan informasi masuk adalah tanggung jawab IdP. Aplikasi atau layanan tidak perlu menyediakan fitur manajemen identitas. Selain itu, dalam skenario perusahaan, direktori perusahaan tidak perlu tahu tentang pengguna jika memercayai IdP. Hal ini menghapus semua overhead administratif dalam mengelola identitas pengguna di dalam direktori.

Masalah dan pertimbangan

Pertimbangkan hal berikut saat mendesain aplikasi yang menerapkan autentikasi terfederasi:

• Autentikasi dapat menjadi satu titik kegagalan. Jika Anda menerapkan aplikasi ke beberapa pusat data, pertimbangkan untuk menyebarkan mekanisme manajemen identitas Anda ke pusat data yang sama untuk menjaga keandalan dan ketersediaan aplikasi.

• Alat autentikasi memungkinkan Anda mengonfigurasi kontrol akses berdasarkan klaim peran yang terkandung dalam token autentikasi. Ini sering disebut sebagai kontrol akses berbasis peran (RBAC) dan dapat memungkinkan tingkat kontrol yang lebih terperinci atas akses ke fitur dan sumber daya.

• Tidak seperti direktori perusahaan, autentikasi berbasis klaim menggunakan IdP sosial biasanya tidak memberikan informasi tentang pengguna yang diautentikasi selain alamat email, dan mungkin nama. Beberapa IdP sosial, seperti akun Microsoft, hanya menyediakan pengidentifikasi unik. Aplikasi biasanya perlu menyimpan beberapa informasi tentang pengguna terdaftar, dan dapat mencocokkan informasi ini dengan pengidentifikasi yang terkandung dalam klaim dalam token. Proses ini biasanya ini dilakukan melalui pendaftaran ketika pengguna pertama kali mengakses aplikasi, lalu informasi dimasukkan ke dalam token sebagai klaim tambahan setelah setiap autentikasi.

• Jika ada lebih dari satu penyedia identitas yang dikonfigurasi untuk STS, STS harus menentukan penyedia identitas mana yang harus dialihkan pengguna untuk autentikasi. Proses ini disebut penemuan realm. STS mungkin dapat melakukannya secara otomatis berdasarkan alamat email atau nama pengguna yang diberikan pengguna, subdomain aplikasi yang diakses pengguna, cakupan alamat IP pengguna, atau pada konten cookie yang disimpan di browser pengguna. Misalnya, jika pengguna memasukkan alamat email di domain Microsoft, seperti user@live.com, STS akan mengalihkan pengguna ke halaman masuk akun Microsoft. Pada kunjungan berikutnya, STS dapat menggunakan cookie untuk menunjukkan bahwa masuk terakhir adalah dengan akun Microsoft. Jika penemuan otomatis tidak dapat menentukan realm asal, STS akan menampilkan halaman penemuan realm asal yang mencantumkan IdP tepercaya, dan pengguna harus memilih salah satu yang ingin mereka gunakan.

Kapan menggunakan pola ini

Pola ini berguna untuk skenario seperti:

• Akses menyeluruh di perusahaan. Dalam skenario ini, Anda perlu mengautentikasi karyawan untuk aplikasi perusahaan yang dihosting di cloud di luar batas keamanan perusahaan, tanpa mengharuskan mereka masuk setiap kali mengunjungi aplikasi. Pengalaman pengguna sama seperti saat menggunakan aplikasi lokal yang diautentikasi saat masuk ke jaringan perusahaan, dan sejak saat itu memiliki akses ke semua aplikasi yang relevan tanpa perlu masuk lagi.

• Identitas terfederasi dengan banyak mitra. Dalam skenario ini, Anda perlu mengautentikasi karyawan perusahaan dan mitra bisnis yang tidak memiliki akun di direktori perusahaan. Hal ini biasa terjadi dalam aplikasi bisnis-ke-bisnis, aplikasi yang terintegrasi dengan layanan pihak ketiga, dan di mana perusahaan dengan sistem TI yang berbeda telah menggabungkan atau membagikan sumber daya.

• Identitas terfederasi dalam aplikasi SaaS. Dalam skenario ini, vendor perangkat lunak independen menyediakan layanan siap pakai untuk beberapa klien atau penyewa. Setiap penyewa mengautentikasi menggunakan IdP yang sesuai. Misalnya, pengguna bisnis akan menggunakan informasi masuk perusahaan mereka, sementara konsumen dan klien penyewa akan menggunakan informasi masuk identitas sosial mereka.

Pola ini mungkin tidak berguna dalam situasi berikut:

• Semua pengguna aplikasi dapat diautentikasi oleh satu IdP, dan tidak ada persyaratan untuk mengautentikasi menggunakan IdP lainnya. Hal ini biasa terjadi pada aplikasi bisnis yang menggunakan direktori perusahaan (dapat diakses dalam aplikasi) untuk autentikasi, dengan menggunakan VPN, atau (dalam skenario yang dihosting di cloud) melalui koneksi jaringan virtual antara direktori lokal dan aplikasi.

• Aplikasi ini awalnya dibangun menggunakan mekanisme autentikasi yang berbeda, mungkin dengan penyimpanan pengguna khusus, atau tidak memiliki kemampuan untuk menangani standar negosiasi yang digunakan oleh teknologi berbasis klaim. Peningkatan autentikasi berbasis klaim dan kontrol akses ke dalam aplikasi yang ada bisa jadi rumit, dan mungkin tidak hemat biaya.

Desain beban kerja

Arsitek harus mengevaluasi bagaimana pola Identitas Federasi dapat digunakan dalam desain beban kerja mereka untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar Azure Well-Architected Framework. Contohnya:

Seperti halnya keputusan desain apa pun, pertimbangkan tradeoff terhadap tujuan pilar lain yang mungkin diperkenalkan dengan pola ini.

Contoh

Organisasi menghosting aplikasi perangkat lunak sebagai layanan (SaaS) multipenyewa di Microsoft Azure. Aplikasi ini mencakup situs web yang dapat digunakan penyewa untuk mengelola aplikasi untuk pengguna mereka sendiri. Aplikasi ini memungkinkan penyewa mengakses situs web menggunakan identitas terfederasi yang dihasilkan oleh Active Directory Federation Services (AD FS) ketika pengguna diautentikasi oleh Active Directory organisasi itu sendiri.

Gambar tersebut menunjukkan bagaimana penyewa mengautentikasi dengan IdP mereka sendiri (langkah 1), dalam hal ini AD FS. Setelah berhasil mengautentikasi penyewa, AD FS akan mengeluarkan token. Browser klien meneruskan token ini ke penyedia federasi aplikasi SaaS, yang memercayai token yang dikeluarkan oleh AD FS penyewa, guna mendapatkan kembali token yang valid untuk penyedia federasi SaaS (langkah 2). Jika perlu, penyedia federasi SaaS melakukan transformasi pada klaim dalam token menjadi klaim yang dikenali aplikasi (langkah 3) sebelum mengembalikan token baru ke browser klien. Aplikasi memercayai token yang dikeluarkan oleh penyedia federasi SaaS dan menggunakan klaim dalam token untuk menerapkan aturan otorisasi (langkah 4).

Penyewa tidak perlu mengingat informasi masuk terpisah untuk mengakses aplikasi, dan administrator di perusahaan penyewa dapat mengonfigurasi dalam AD FS-nya sendiri, yaitu daftar pengguna yang dapat mengakses aplikasi.

Langkah berikutnya

• Microsoft Entra ID
• Active Directory Domain Services
• Layanan Federasi Direktori Aktif
• Aplikasi Multipenyewa di Azure

Sumber daya terkait

• Pengelolaan identitas untuk aplikasi multi-penyewa di Microsoft Azure
• Pola penjaga gerbang
• Pola Konfigurasi Beban Kerja Edge
• Pola Komputasi Konsolidasi Sumber Daya
• Pola Gateway Offloading