Bagikan melalui

Panduan Microsoft Entra Conditional Access untuk pengembang

  • Artikel

Fitur Akses Bersyar di ID Microsoft Entra menawarkan salah satu dari beberapa cara yang dapat Anda gunakan untuk mengamankan aplikasi Anda dan melindungi layanan. Akses Bersyarat memungkinkan pengembang dan pelanggan perusahaan untuk melindungi layanan dalam berbagai cara termasuk:

  • Autentikasi multifaktor
  • Hanya mengizinkan perangkat terdaftar Intune untuk mengakses layanan tertentu
  • Membatasi lokasi pengguna dan rentang IP

Untuk informasi selengkapnya tentang kemampuan penuh Akses Bersyarat, lihat artikel Apa itu Akses Bersyarat.

Untuk pengembang yang membangun aplikasi untuk ID Microsoft Entra, artikel ini memperlihatkan bagaimana Anda dapat menggunakan Akses Bersyar dan Anda juga akan mempelajari tentang dampak mengakses sumber daya yang tidak memiliki kontrol atas kebijakan Akses Bersyarah yang mungkin diterapkan. Artikel ini juga mengeksplorasi implikasi Akses Bersyarat dalam aliran, aplikasi web, mengakses Microsoft Graph, dan memanggil API.

Pengetahuan tentang aplikasi tunggal dan multipenyewa dan pola autentikasi umum diasumsikan .

Catatan

Fitur ini memerlukan lisensi Microsoft Entra ID P1 agar dapat digunakan. Untuk menemukan lisensi yang tepat untuk kebutuhan Anda, lihat Membandingkan fitur dari edisi Gratis, Dasar, dan Premium yang tersedia secara umum. Pelanggan dengan lisensi Microsoft 365 Business Premium juga memiliki akses ke fitur Akses Bersyarat.

Bagaimana Akses Bersyarat memengaruhi aplikasi?

Jenis aplikasi terdampak

Dalam kebanyakan kasus umum, Akses Bersyarat tidak mengubah perilaku aplikasi atau memerlukan perubahan apa pun dari pengembang. Hanya dalam kasus tertentu ketika aplikasi secara tidak langsung atau diam-diam meminta token untuk layanan, aplikasi memerlukan perubahan kode untuk menangani tantangan Akses Bersyarat. Ini mungkin sesederhana melakukan permintaan masuk interaktif.

Secara khusus, skenario berikut ini memerlukan kode untuk menangani tantangan Akses Bersyarat:

  • Aplikasi yang menjalankan aliran on-behalf-of
  • Aplikasi yang mengakses beberapa layanan/sumber daya
  • Aplikasi satu halaman menggunakan MSAL.js
  • Aplikasi web memanggil sumber daya

Kebijakan Akses Bersyarat dapat diterapkan ke aplikasi, tetapi juga dapat diterapkan ke API web akses aplikasi Anda. Untuk mempelajari selengkapnya tentang cara mengonfigurasi kebijakan Akses Bersyarat, lihat Mulai Cepat: Memerlukan MFA untuk aplikasi tertentu dengan Akses Bersyarat Microsoft Entra.

Bergantung pada skenarionya, pelanggan perusahaan dapat menerapkan dan menghapus kebijakan Akses Bersyarat kapan saja. Agar aplikasi Anda terus berfungsi saat kebijakan baru diterapkan, terapkan penanganan tantangan. Contoh berikut menggambarkan penanganan tantangan.

Contoh Akses Bersyarat

Beberapa skenario memerlukan perubahan kode untuk menangani Akses Bersyarat sedangkan yang lain berfungsi apa adanya. Berikut adalah beberapa skenario menggunakan Akses Bersyarat untuk melakukan autentikasi multifaktor yang memberikan beberapa wawasan tentang perbedaannya.

  • Anda sedang membangun aplikasi iOS penyewa tunggal dan menerapkan kebijakan Akses Bersyarat. Aplikasi masuk ke pengguna dan tidak meminta akses ke API. Saat pengguna masuk, kebijakan secara otomatis dipanggil dan pengguna perlu melakukan autentikasi multifaktor (MFA).
  • Anda sedang membangun aplikasi asli yang menggunakan layanan tingkat menengah untuk mengakses API hilir. Pelanggan perusahaan di perusahaan yang menggunakan aplikasi ini menerapkan kebijakan ke API hilir. Saat pengguna akhir masuk, aplikasi native meminta akses ke tingkat tengah dan mengirim token. Tingkat tengah melakukan aliran on-behalf-of untuk meminta akses ke API hilir. Pada titik ini, klaim "tantangan" disajikan ke tingkat tengah. Tingkat tengah mengirimkan tantangan kembali ke aplikasi native, yang perlu mematuhi kebijakan Akses Bersyarat.

Microsoft Graph

Microsoft Graph memiliki pertimbangan khusus saat membuat aplikasi di lingkungan Akses Bersyarat. Umumnya, mekanisme Akses Bersyarat berperilaku sama, tetapi kebijakan yang dilihat pengguna Anda akan didasarkan pada data yang mendasari yang meminta aplikasi Anda dari grafik.

Secara khusus, semua lingkup Microsoft Graph mewakili beberapa set data yang dapat diterapkan secara individual. Karena kebijakan Akses Bersyar diberikan himpunan data tertentu, MICROSOFT Entra ID memberlakukan kebijakan Akses Bersyar berdasarkan data di belakang Grafik - bukan Grafik itu sendiri.

Misalnya, jika aplikasi meminta cakupan Microsoft Graph berikut,

scopes="ChannelMessages.Read.All Mail.Read"

Aplikasi dapat mengharapkan pengguna mereka memenuhi semua kebijakan yang ditetapkan di Teams dan Exchange. Beberapa cakupan dapat memetakan ke beberapa himpunan data jika memberikan akses.

Mematuhi kebijakan Akses Bersyarat

Untuk beberapa topologi aplikasi yang berbeda, kebijakan Akses Bersyarat dievaluasi saat sesi ditetapkan. Sebagai kebijakan Akses Bersyarat beroperasi pada granularitas aplikasi dan layanan, titik di mana ia dipanggil sangat tergantung pada skenario yang ingin Anda capai.

Ketika aplikasi Anda mencoba mengakses layanan dengan kebijakan Akses Bersyarat, aplikasi tersebut mungkin mengalami tantangan Akses Bersyarat. Tantangan ini dikodekan dalam claims parameter yang datang dalam respons dari ID Microsoft Entra. Berikut adalah contoh parameter tantangan ini:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Pengembang dapat mengambil tantangan ini dan menambahkannya ke permintaan baru ke ID Microsoft Entra. Melewati status ini meminta pengguna akhir untuk melakukan tindakan apa pun yang diperlukan untuk mematuhi kebijakan Akses Bersyarat. Dalam skenario berikut, spesifik kesalahan dan cara mengekstrak parameter dijelaskan.

Skenario

Prasyarat

Microsoft Entra Conditional Access adalah fitur yang disertakan dalam Microsoft Entra ID P1 atau P2. Pelanggan dengan lisensi Microsoft 365 Business Premium juga memiliki akses ke fitur Akses Bersyarat.

Pertimbangan untuk skenario tertentu

Informasi berikut ini hanya berlaku dalam skenario Akses Bersyarat ini:

  • Aplikasi yang menjalankan aliran on-behalf-of
  • Aplikasi yang mengakses beberapa layanan/sumber daya
  • Aplikasi satu halaman menggunakan MSAL.js

Bagian berikut membahas skenario umum yang lebih kompleks. Prinsip operasi intinya adalah kebijakan Akses Bersyarat dievaluasi pada saat token diminta untuk layanan yang memiliki kebijakan Akses Bersyarat yang diterapkan.

Skenario: Aps yang berperforma atas nama aliran

Dalam skenario ini, kita berjalan melalui kasus di mana aplikasi native memanggil layanan web / API. Pada gilirannya, layanan ini melakukan aliran "atas nama" untuk memanggil layanan hilir. Dalam kasus kami, kami telah menerapkan kebijakan Akses Bersyarat kami ke layanan hilir (Web API 2) dan menggunakan aplikasi native daripada aplikasi server / daemon.

App performing the on-behalf-of flow diagram

Permintaan token awal untuk Web API 1 tidak meminta autentikasi multifaktor kepada pengguna akhir karena Web API 1 mungkin tidak selalu mencapai API hilir. Setelah Web API 1 mencoba meminta token atas nama pengguna untuk Web API 2, permintaan gagal karena pengguna belum masuk dengan autentikasi multifaktor.

MICROSOFT Entra ID mengembalikan respons HTTP dengan beberapa data menarik:

Catatan

Dalam hal ini adalah deskripsi kesalahan autentikasi multifaktor, tetapi ada interaction_required berbagai kemungkinan berkaitan dengan Akses Bersyarat.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

Di Web API 1, kami menangkap kesalahan error=interaction_required, dan mengirim kembali tantangan ke aplikasi claims desktop. Pada saat itu, aplikasi desktop dapat melakukan panggilan acquireToken() baru dan menambahkan claimstantangan sebagai parameter string kueri tambahan. Permintaan baru ini mengharuskan pengguna untuk melakukan autentikasi multifaktor dan kemudian mengirim token baru ini kembali ke Web API 1 dan menyelesaikan alur atas nama.

Untuk mencoba skenario ini, lihat contoh kode .NET kami. Ini menunjukkan cara meneruskan tantangan klaim kembali dari Web API 1 ke aplikasi native dan membangun permintaan baru di dalam aplikasi klien.

Skenario: Aplikasi mengakses beberapa layanan

Dalam skenario ini, kita berjalan melalui kasus di mana aplikasi web mengakses dua layanan salah satunya memiliki kebijakan Akses Bersyarat yang ditetapkan. Bergantung pada logika aplikasi Anda, mungkin ada jalur di mana aplikasi Anda tidak memerlukan akses ke kedua layanan web. Dalam skenario ini, urutan di mana Anda meminta token memainkan peran penting dalam pengalaman pengguna akhir.

Mari kita asumsikan kita memiliki layanan web A dan B dan layanan web B memiliki kebijakan Akses Bersyarat kami diterapkan. Meskipun permintaan auth interaktif awal memerlukan persetujuan untuk kedua layanan, kebijakan Akses Bersyarat tidak diperlukan dalam semua kasus. Jika aplikasi meminta token untuk layanan web B, maka kebijakan dipanggil dan permintaan berikutnya untuk layanan web A juga berhasil sebagai berikut.

App accessing multiple-services flow diagram

Atau, jika aplikasi awalnya meminta token untuk layanan web A, pengguna akhir tidak memanggil kebijakan Akses Bersyarat. Hal ini memungkinkan pengembang aplikasi untuk mengontrol pengalaman pengguna akhir dan tidak memaksa kebijakan Akses Bersyarat untuk dipanggil dalam semua kasus. Kasus rumitnya adalah jika aplikasi nanti meminta token untuk layanan web B. Pada titik ini, pengguna akhir perlu mematuhi kebijakan Akses Bersyar. Ketika aplikasi mencoba untuk acquireToken, itu dapat menghasilkan kesalahan berikut (diilustrasikan dalam diagram berikut):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

Jika aplikasi menggunakan pustaka MSAL, kegagalan untuk memperoleh token selalu dicoba secara interaktif. Ketika permintaan interaktif ini terjadi, pengguna akhir memiliki kesempatan untuk mematuhi Akses Bersyarat. Ini benar kecuali permintaan adalah AcquireTokenSilentAsync atau PromptBehavior.Never dalam hal ini aplikasi perlu melakukan permintaan AcquireToken interaktif untuk memberi pengguna akhir kesempatan untuk mematuhi kebijakan.

Skenario: Aplikasi satu halaman (SPA) menggunakan MSAL.js

Dalam skenario ini, kita berjalan melalui kasus ketika kita memiliki aplikasi satu halaman (SPA) memanggil API web yang dilindungi Akses Bersyarat menggunakan MSAL.js. Ini adalah arsitektur sederhana tetapi memiliki beberapa nuansa yang perlu diperhitungkan ketika mengembangkan sekitar Akses Bersyarat.

Dalam MSAL.js, ada beberapa fungsi yang mendapatkan token: acquireTokenSilent(), acquireTokenPopup(), dan acquireTokenRedirect().

  • acquireTokenSilent() dapat digunakan untuk diam-diam mendapatkan token akses yang berarti tidak menunjukkan UI dalam keadaan apa pun.
  • acquireTokenPopup() dan acquireTokenRedirect() keduanya digunakan untuk secara interaktif meminta token untuk sumber daya yang berarti mereka selalu menampilkan UI masuk.

Ketika aplikasi memerlukan token akses untuk memanggil API web, aplikasi akan mencoba acquireTokenSilent(). Jika token kedaluwarsa atau kita perlu mematuhi kebijakan Akses Bersyarat, maka fungsi acquireToken gagal dan aplikasi menggunakan acquireTokenPopup() atau acquireTokenRedirect().

Single-page app using MSAL flow diagram

Mari kita hingga contoh dengan skenario Akses Bersyarat kami. Pengguna akhir baru saja mendarat di situs dan tidak memiliki sesi. Kami melakukan loginPopup() panggilan, mendapatkan token ID tanpa autentikasi multifaktor. Kemudian pengguna menekan tombol yang mengharuskan aplikasi untuk meminta data dari API web. Aplikasi mencoba melakukan acquireTokenSilent() panggilan tetapi gagal karena pengguna belum melakukan autentikasi multifaktor dan perlu mematuhi kebijakan Akses Bersyariah.

MICROSOFT Entra ID mengirimkan kembali respons HTTP berikut:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Aplikasi kami perlu menangkap error=interaction_required. Aplikasi kemudian dapat menggunakan salah satu acquireTokenPopup() atau acquireTokenRedirect() pada sumber daya yang sama. Pengguna dipaksa untuk melakukan autentikasi multifaktor. Setelah pengguna menyelesaikan autentikasi multifaktor, aplikasi akan mengeluarkan token akses baru untuk sumber daya yang diminta.

Untuk mencoba skenario ini, lihat panggilan React SPA kami Node.js API web menggunakan sampel kode alur atas nama. Sampel kode ini menggunakan kebijakan Akses Bersyariah dan API web yang Anda daftarkan sebelumnya dengan React SPA untuk menunjukkan skenario ini. Ini menunjukkan cara menangani tantangan klaim dengan benar dan mendapatkan token akses yang dapat digunakan untuk API web Anda.

Lihat juga