Pola Identitas Terfederasi

Delegasikan autentikasi pengguna ke Penyedia Identitas Eksternal (IdP) untuk menyederhanakan pengembangan, meminimalkan tugas administratif, dan meningkatkan UX aplikasi.

Konteks dan masalah

Pengguna biasanya perlu bekerja dengan beberapa aplikasi yang disediakan dan dihosting oleh organisasi mitra. Mereka mungkin perlu menggunakan kredensial masuk tertentu yang berbeda untuk setiap aplikasi. Persyaratan ini dapat:

• Menyebabkan UX yang terputus-putus. Karyawan sering lupa beberapa kredensial masuk.

• Mengekspos kerentanan keamanan. Ketika karyawan keluar dari perusahaan, organisasi harus segera menonaktifkan akun. Organisasi besar sering melewatkan langkah penting ini.

• Manajemen pengguna yang rumit. Admin mengelola kredensial pengguna, mengeluarkan pengingat kata sandi, dan melakukan tugas administratif lainnya.

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

Solusi

Menerapkan mekanisme autentikasi identitas federasi. Pisahkan autentikasi pengguna dari kode aplikasi dan delegasikan autentikasi ke IdP tepercaya. Proses ini menyederhanakan pengembangan, meminimalkan overhead administratif, dan menyediakan autentikasi pengguna melalui berbagai IdP. Identitas gabungan juga memisahkan autentikasi dari otorisasi.

IdP tepercaya termasuk direktori perusahaan, layanan federasi lokal, layanan token keamanan (STS), dan IDP sosial seperti Microsoft, Google, Yahoo!, atau Facebook.

Diagram berikut menunjukkan pola Identitas Federasi untuk aplikasi klien yang mengakses layanan yang memerlukan autentikasi. IdP bekerja dengan STS untuk menyediakan autentikasi. IdP mengeluarkan token keamanan yang memberikan informasi tentang pengguna yang diautentikasi. Informasi ini, yang disebut klaim, mencakup identitas pengguna dan mungkin juga menyertakan klaim lain, seperti keanggotaan peran dan hak akses yang lebih terperinci.

Diagram yang memperlihatkan pola Identitas Terfederasi. Pada langkah 1, sebuah panah menghubungkan kotak berlabel "service" ke kotak berlabel "identity provider" (IdP) atau "security token service" (STS). Panah diberi label layanan mempercayai IdP atau STS. Pada langkah 2, sebuah panah menghubungkan kotak berlabel consumer ke kotak berlabel IdP atau STS. Panah tersebut diberi label "konsumen melakukan autentikasi dan meminta token". Di langkah 3, panah menyambungkan kotak berlabel IdP atau STS kembali ke kotak berlabel konsumen. Panah tersebut berlabel "STS returns token". Pada langkah 4, sebuah panah menghubungkan kotak berlabel "consumer" ke kotak berlabel "service". Panah tersebut diberi label "konsumen menyerahkan token ke layanan".

Model ini juga disebut kontrol akses berbasis klaim. Aplikasi dan layanan mengotorisasi akses ke fitur dan fungsionalitas berdasarkan klaim. Layanan yang memerlukan autentikasi harus memercayai IdP. Aplikasi klien menghubungi IdP untuk autentikasi. Jika autentikasi berhasil, IdP mengembalikan token yang berisi klaim pengidentifikasi pengguna ke STS. IdP dan STS mungkin menjadi bagian dari layanan yang sama. STS dapat mengubah dan menambah klaim berdasarkan aturan yang telah ditentukan sebelum mengembalikan token ke klien. Aplikasi klien kemudian meneruskan token ini ke layanan sebagai bukti identitasnya.

Autentikasi federasi menyediakan metode berbasis standar untuk membangun kepercayaan pada identitas di seluruh domain, dan mendukung akses menyeluruh (SSO). Banyak aplikasi, terutama aplikasi yang dihosting cloud, menggunakan autentikasi federasi karena mendukung SSO tanpa koneksi jaringan langsung ke IdP. Desain ini meningkatkan keamanan, karena pengguna tidak perlu membuat dan memasukkan kredensial masuk yang berbeda untuk beberapa aplikasi. Ini juga membatasi paparan kredensial hanya pada IdP asli. Aplikasi hanya melihat informasi identitas terautentikasi dalam token.

Aplikasi dan layanan yang menggunakan autentikasi federasi tidak perlu menyediakan fitur manajemen identitas. Sebaliknya, IdP bertanggung jawab atas manajemen identitas dan kredensial. Ketika direktori perusahaan mempercayai IdP, direktori tersebut tidak perlu mengelola identitas pengguna. Pendekatan ini menghilangkan overhead administratif manajemen identitas pengguna berbasis direktori.

Masalah dan pertimbangan

Pertimbangkan poin-poin berikut saat Anda memutuskan cara menerapkan pola ini:

• Autentikasi dapat menjadi satu titik kegagalan. Untuk mempertahankan keandalan dan ketersediaan aplikasi di beberapa wilayah, pertimbangkan untuk menyebarkan mekanisme manajemen identitas Anda di seluruh wilayah yang sama dengan aplikasi Anda.

• Untuk mengonfigurasi kontrol akses berbasis peran (RBAC), gunakan alat autentikasi. RBAC mendukung kontrol terperinci atas fitur dan akses sumber daya.

• Tidak seperti direktori perusahaan, autentikasi berbasis klaim yang menggunakan IDP sosial biasanya hanya menyediakan alamat email pengguna yang diautentikasi, dan terkadang namanya. Beberapa IDP sosial, seperti Microsoft, hanya menyediakan pengidentifikasi unik. Aplikasi biasanya menyimpan beberapa informasi tentang pengguna terdaftar sehingga dapat mencocokkan informasi ini dengan pengidentifikasi dalam klaim. Tugas ini biasanya selesai selama pendaftaran, ketika pengguna pertama kali mengakses aplikasi. Informasi kemudian disuntikkan ke token sebagai klaim baru setelah setiap autentikasi.

• Jika beberapa IdP dikonfigurasi untuk STS, STS harus menentukan IdP mana yang harus mengautentikasi pengguna. Proses ini disebut home realm discovery. STS dapat menentukan IdP secara otomatis berdasarkan informasi yang disediakan pengguna seperti alamat email atau nama pengguna, subdomain aplikasi, rentang alamat IP pengguna, atau cookie yang disimpan di browser pengguna. Misalnya, jika pengguna memasukkan alamat email Microsoft, seperti user@live.com, STS mengalihkan pengguna ke halaman masuk akun Microsoft. Pada kunjungan berikutnya, STS dapat menggunakan cookie yang menunjukkan pengguna yang sebelumnya masuk dengan menggunakan akun Microsoft. Jika STS tidak dapat secara otomatis menentukan realm asal, STS akan menampilkan halaman penemuan realm asal yang mencantumkan IdP tepercaya. Pengguna kemudian memilih IdP.

Kapan menggunakan pola ini

Gunakan pola ini saat Anda membutuhkan:

• SSO di perusahaan. Dalam skenario ini, Anda perlu mengautentikasi karyawan untuk aplikasi perusahaan yang dihosting di cloud di luar batas keamanan perusahaan, tanpa masuk setiap kali mereka mengunjungi aplikasi. Pengalaman pengguna cocok dengan aplikasi lokal. Pengguna mengautentikasi saat mereka masuk ke jaringan perusahaan, dan kemudian mereka dapat mengakses aplikasi yang relevan tanpa masuk lain.

• Identitas terfederasi dengan beberapa mitra. Dalam skenario ini, Anda perlu mengautentikasi karyawan perusahaan dan mitra bisnis yang tidak memiliki akun di direktori perusahaan. Praktik ini umum dalam aplikasi bisnis-ke-bisnis, aplikasi yang terintegrasi dengan layanan mitra, dan di perusahaan yang menggunakan sistem IT yang berbeda, atau sumber daya gabungan atau bersama.

• Identitas gabungan dalam aplikasi perangkat lunak sebagai layanan (SaaS). Dalam skenario ini, vendor perangkat lunak independen menyediakan layanan siap pakai untuk beberapa klien atau penyewa. Penyewa mengautentikasi dengan menggunakan IdP yang sesuai. Misalnya, pengguna bisnis menggunakan kredensial perusahaan mereka, sementara konsumen penyewa dan klien menggunakan kredensial identitas sosial.

• Identitas gabungan untuk akses beban kerja. Dalam skenario ini, aplikasi penyewa, alur kerja otomatisasi, atau integrasi berkelanjutan dan sistem pengiriman berkelanjutan perlu memanggil API Anda tanpa ada pengguna. Penyewa melakukan autentikasi melalui IdP mereka sendiri dengan menggunakan identitas beban kerja. Aplikasi mengotorisasi akses dengan menggunakan validasi klaim yang dilingkup penyewa.

Pola ini mungkin tidak cocok ketika Anda memiliki:

• Satu IdP. Dalam skenario ini, pengguna aplikasi mengautentikasi dengan menggunakan satu IdP, dan mereka tidak perlu mengautentikasi dengan menggunakan IdP lain. Situasi ini khas dalam aplikasi yang menggunakan direktori perusahaan untuk autentikasi, baik melalui VPN atau koneksi jaringan virtual antara aplikasi dan direktori lokal.

• Mekanisme autentikasi yang tidak kompatibel. Dalam skenario ini, aplikasi menggunakan mekanisme autentikasi yang berbeda, misalnya dengan menggunakan penyimpanan pengguna kustom, atau tidak dapat menangani standar negosiasi teknologi berbasis klaim. Ini bisa menjadi kompleks dan mahal untuk retrofit autentikasi berbasis klaim dan kontrol akses ke dalam aplikasi yang ada.

Desain beban kerja

Evaluasi cara menggunakan pola Identitas Federasi dalam desain beban kerja untuk mengatasi tujuan dan prinsip yang tercakup dalam pilar kerangka kerja Azure Well-Architected. Tabel berikut memberikan panduan tentang bagaimana pola ini mendukung tujuan setiap pilar.

Prinsip Dasar	Bagaimana pola ini mendukung tujuan pilar
Keputusan desain Keandalan membantu beban kerja Anda menjadi tangguh tidak berfungsi dan memastikan bahwa memulihkan ke keadaan yang berfungsi penuh setelah kegagalan terjadi.	Pola ini mengalihkan pengelolaan dan autentikasi pengguna ke IdP, yang biasanya memiliki sasaran tingkat layanan yang tinggi. Selama pemulihan bencana beban kerja (DR), rencana pemulihan beban kerja tidak perlu mengatasi komponen autentikasi. - RE:02 Alur Kritis - RE:09 DR
Keputusan desain keamanan membantu memastikan kerahasiaan, integritas, dan ketersediaan data dan sistem beban kerja Anda.	Pola ini menyediakan kemampuan deteksi dan pencegahan ancaman berbasis identitas tingkat lanjut tanpa mengharuskan Anda menerapkannya dalam beban kerja Anda. IDP eksternal juga menggunakan protokol autentikasi modern yang dapat dioperasikan. - Siklus hidup pengembangan aman SE:02 - Pemantauan SE:10 dan deteksi ancaman
Efisiensi Performa membantu beban kerja Anda memenuhi permintaan secara efisien melalui pengoptimalan dalam penskalaan, data, dan kode.	Pola ini membantu Anda mengalokasikan sumber daya aplikasi untuk prioritas lain. - PE:03 Memilih layanan

Jika pola ini memperkenalkan kompromi di dalam pilar, bandingkan dengan tujuan pilar lain.

Example

Organisasi menghosting aplikasi berbasis cloud multikomponen yang menyertakan front end web dan API back-end. Aplikasi mendelegasikan autentikasi ke IdP terpusat dengan menggunakan Microsoft Entra ID, daripada menerapkan logika autentikasi di setiap komponen.

Diagram yang memperlihatkan pola Identitas Federasi dengan autentikasi Microsoft Entra ID. Judul diagram Microsoft Entra ID – Kode Otorisasi + PKCE. Ada empat kotak, pengguna berlabel, aplikasi web, Microsoft Entra ID, dan API. Pengguna tersambung ke aplikasi web dengan panah berlabel aplikasi terbuka dan memilih masuk. Aplikasi web terhubung ke Microsoft Entra ID dengan panah yang berlabel "redirect" untuk autentikasi. Microsoft Entra ID tersambung kembali ke aplikasi web dengan panah putus-putus berlabel pengalihan ke aplikasi dengan kode autentikasi. Aplikasi web terhubung kembali ke Microsoft Entra ID dengan panah berlabel POST token (authorization_code + verifikator kode). Microsoft Entra ID tersambung kembali ke aplikasi web dengan panah putus-putus berlabel token ID, token akses, dan token refresh. Aplikasi web terhubung ke API dengan panah yang melewati Microsoft Entra ID. Panah diberi label memanggil API dengan menggunakan token akses. API memvalidasi token dan memberlakukan otorisasi. API terhubung kembali ke aplikasi web dengan panah putus-putus yang melewati Microsoft Entra ID. Panah diberi label respons.

Unduh file Visio dari arsitektur ini.

Alur kerja berikut ini sesuai dengan diagram sebelumnya.

1. Pengguna mengakses aplikasi web.

2. Aplikasi web mengalihkan pengguna ke Microsoft Entra ID untuk autentikasi.

3. Setelah autentikasi berhasil, Microsoft Entra ID mengalihkan pengguna kembali ke aplikasi web dengan kode otorisasi.

4. Aplikasi web bertukar kode otorisasi untuk token dan mengirim permintaan POST ke titik akhir token.

5. Microsoft Entra ID mengeluarkan token yang berisi klaim tentang pengguna.

6. Aplikasi web menggunakan token ini untuk memanggil API back-end.

7. Aplikasi web dan API back-end memvalidasi token dan menerapkan aturan otorisasi mereka berdasarkan klaim.

8. API mengembalikan respons ke aplikasi web.

Karakteristik utama:

• Autentikasi terpusat. Komponen mengandalkan Microsoft Entra ID untuk mengautentikasi pengguna, yang menghapus kebutuhan akan logika autentikasi kustom dalam aplikasi.

• Otorisasi terdesentralisasi. Komponen aplikasi secara independen menerapkan keputusan otorisasi berdasarkan klaim.

• Kontrol akses berbasis klaim. Akses ke fungsionalitas ditentukan dengan menggunakan klaim, seperti peran atau cakupan.

• Protokol berbasis standar. Komponen menggunakan OAuth 2.0 dan OpenID Connect untuk autentikasi.

• Penerapan MFA opsional. Jika profil risiko Anda memerlukan jaminan masuk yang lebih kuat, Anda dapat menerapkan autentikasi multifaktor dengan menggunakan kebijakan Akses Bersyarat di Microsoft Entra ID.

• Ekstensibilitas opsional melalui federasi. Microsoft Entra ID dapat dikonfigurasi untuk memercayai tenant mitra Microsoft Entra dengan menggunakan pengaturan akses lintas penyewa. Pengguna mitra kemudian dapat mengakses aplikasi tanpa perubahan pada komponen aplikasi.

Langkah berikutnya

• Apa itu Microsoft Entra?
• OpenID Connect di platform identitas Microsoft
• Mengonversi aplikasi penyewa tunggal ke multipenyewa dengan menggunakan Microsoft Entra ID
• Apa itu Akses Bersyarat?

Sumber daya terkait

• Pertimbangan arsitektur untuk identitas dalam solusi multipenyewa
• Pola penjaga gerbang
• Pola Kunci Valet
• Pola Desain Gateway Offloading