Konsep Koneksi/OAuth OpenID Layanan Federasi Direktori Aktif

  • Artikel
  • 8 menit untuk membaca

Berlaku untuk Layanan Federasi Direktori Aktif 2016 dan yang lebih baru

Aktor Autentikasi Modern

Actor Deskripsi
Pengguna Akhir Ini adalah prinsip keamanan (pengguna, aplikasi, layanan, dan grup) yang perlu mengakses sumber daya.
Klien Ini adalah aplikasi web Anda, yang diidentifikasi oleh ID kliennya. Klien biasanya adalah pihak yang berinteraksi dengan pengguna akhir, dan meminta token dari server otorisasi.
Server Otorisasi / Penyedia Identitas (IdP) Ini adalah server Layanan Federasi Direktori Aktif Anda. Ini bertanggung jawab untuk memverifikasi identitas prinsip keamanan yang ada di direktori organisasi. Ini mengeluarkan token keamanan (token akses pembawa, token ID, token refresh) setelah keberhasilan autentikasi prinsip keamanan tersebut.
Server Sumber Daya / Penyedia Sumber Daya / Pihak yang Mengandalkan Di sinilah sumber daya atau data berada. Ini mempercayai Server Otorisasi untuk mengautentikasi dan mengotorisasi Klien dengan aman dan menggunakan token akses Pembawa untuk memastikan bahwa akses ke sumber daya dapat diberikan.

Diagram berikut menyediakan hubungan paling mendasar antara aktor:

Modern Authentication actors

Jenis Aplikasi

Jenis Aplikasi Deskripsi Peran
Aplikasi asli Terkadang disebut klien publik, ini dimaksudkan untuk menjadi aplikasi klien yang berjalan pada pc atau perangkat dan dengan mana pengguna berinteraksi. Meminta token dari server otorisasi (AD FS) untuk akses pengguna ke sumber daya. Mengirim permintaan HTTP ke sumber daya yang dilindungi, menggunakan token sebagai header HTTP.
Aplikasi server (Aplikasi web) Aplikasi web yang berjalan di server dan umumnya dapat diakses oleh pengguna melalui browser. Karena mampu mempertahankan 'rahasia' atau kredensial kliennya sendiri, terkadang disebut klien rahasia. Meminta token dari server otorisasi (AD FS) untuk akses pengguna ke sumber daya. Sebelum meminta token, klien (Aplikasi Web) perlu mengautentikasi menggunakan rahasianya.
API Web Sumber daya akhir yang diakses pengguna. Anggap ini sebagai representasi baru "pihak yang mengandalkan". Mengonsumsi token akses pembawa yang diperoleh oleh klien

Grup Aplikasi

Setiap klien OAuth (aplikasi asli atau web) atau sumber daya (api web) yang dikonfigurasi dengan Layanan Federasi Direktori Aktif perlu dikaitkan dengan grup aplikasi. Klien dalam grup aplikasi dapat dikonfigurasi untuk mengakses sumber daya dalam grup yang sama. Grup aplikasi dapat berisi beberapa klien dan sumber daya.

Token Keamanan

Autentikasi modern menggunakan jenis token berikut:

  • id_token: Token JWT yang dikeluarkan oleh server otorisasi (AD FS) dan digunakan oleh klien. Klaim dalam token ID akan berisi informasi tentang pengguna sehingga klien dapat menggunakannya.
  • access_token: Token JWT yang dikeluarkan oleh server otorisasi (AD FS) dan dimaksudkan untuk digunakan oleh sumber daya. Klaim 'aud' atau audiens token ini harus cocok dengan pengidentifikasi sumber daya atau WEB API.
  • refresh_token: Ini adalah token yang dikeluarkan oleh Layanan Federasi Direktori Aktif untuk digunakan klien saat perlu merefresh id_token dan access_token. Token buram untuk klien dan hanya dapat dikonsumsi oleh Layanan Federasi Direktori Aktif.

Masa Pakai Token Refresh

  • Masuk sederhana (tidak ada KMSI, perangkat yang tidak terdaftar): Layanan Federasi Direktori Aktif akan menerapkan SsoLifetime + DeviceUsageWindowInDays, dan token refresh pertama akan memiliki masa pakai=DeviceUsageWindowInDays atau SsoLifetime (berdasarkan bidang mana yang lebih rendah), tetapi tidak ada token refresh lebih lanjut yang dikeluarkan.
  • Masuk KMSI (EnableKmsi=true di AD FS conf dan kmsi=true passed as parameter): AD FS akan menerapkan KmsiLifetimeMins dengan DeviceUsageWindowInDays. Token refresh pertama akan memiliki lifetime=DeviceUsageWindowInDays dan setiap permintaan grant_type=refresh_token berikutnya akan mendapatkan refresh_token baru. (Ini hanya terjadi dengan klien asli atau klien rahasia + autentikasi perangkat)
  • Perangkat terdaftar (autentikasi perangkat): Layanan Federasi Direktori Aktif akan menggunakan PersistentSsoLifetimeMins + DeviceUsageWindowInDays yang mirip dengan KMSI. Klien Asli dan Rahasia harus mendapatkan token refresh baru (berdasarkan autentikasi perangkat).

Detail tambahan dalam dokumentasi Akses Menyeluruh Layanan Federasi Direktori Aktif

Cakupan

Saat mendaftarkan sumber daya di Layanan Federasi Direktori Aktif, cakupan dapat dikonfigurasi untuk memungkinkan Layanan Federasi Direktori Aktif melakukan tindakan tertentu. Selain mengonfigurasi cakupan, nilai cakupan juga harus dikirim dalam permintaan LAYANAN Federasi Direktori Aktif untuk melakukan tindakan. Misalnya, Admin perlu mengonfigurasi cakupan sebagai openid selama pendaftaran sumber daya dan aplikasi (klien) perlu mengirim cakupan = openid dalam permintaan autentikasi untuk AD FS untuk mengeluarkan Token ID. Detail tentang cakupan yang tersedia di Layanan Federasi Direktori Aktif disediakan di bawah ini

  • aza - Jika menggunakan Ekstensi Protokol OAuth 2.0 untuk Klien Broker dan jika parameter cakupan berisi cakupan "aza", server mengeluarkan token refresh utama baru dan mengaturnya di bidang respons refresh_token, serta mengatur bidang refresh_token_expires_in ke masa pakai token refresh utama baru jika diberlakukan.
  • openid - Memungkinkan aplikasi untuk meminta penggunaan protokol otorisasi Koneksi OpenID.
  • logon_cert - Cakupan logon_cert memungkinkan aplikasi untuk meminta sertifikat masuk, yang dapat digunakan untuk masuk secara interaktif pada pengguna yang diautentikasi. Server Layanan Federasi Direktori Aktif menghilangkan parameter access_token dari respons dan sebaliknya menyediakan rantai sertifikat CMS yang dikodekan base64 atau respons PKI penuh CMC. Detail selengkapnya tersedia di sini.
  • user_impersonation - Cakupan user_impersonation diperlukan agar berhasil meminta token akses atas nama dari Layanan Federasi Direktori Aktif. Untuk detail tentang cara menggunakan cakupan ini, lihat Membangun aplikasi multi-tingkat menggunakan On-Behalf-Of (OBO) menggunakan OAuth dengan AD FS 2016.
  • allatclaims – Cakupan allatclaims memungkinkan aplikasi untuk meminta klaim dalam token akses untuk ditambahkan dalam Token ID juga.
  • vpn_cert - Cakupan vpn_cert memungkinkan aplikasi untuk meminta sertifikat VPN, yang dapat digunakan untuk membuat koneksi VPN menggunakan autentikasi EAP-TLS. Ini tidak didukung lagi.
  • email - Memungkinkan aplikasi untuk meminta klaim email untuk pengguna yang masuk.
  • profile - Memungkinkan aplikasi untuk meminta klaim terkait profil untuk pengguna masuk.

Klaim

Token keamanan (akses dan token ID) yang dikeluarkan oleh Layanan Federasi Direktori Aktif berisi klaim, atau pernyataan informasi tentang subjek yang telah diautentikasi. Aplikasi dapat menggunakan klaim untuk berbagai tugas, termasuk:

  • Memvalidasi token
  • Mengidentifikasi penyewa direktori subjek
  • Menampilkan informasi pengguna
  • Menentukan otorisasi subjek

Klaim yang ada dalam token keamanan tertentu tergantung pada jenis token, jenis info masuk yang digunakan untuk mengautentikasi pengguna, dan konfigurasi aplikasi.

Alur autentikasi LAYANAN Federasi Direktori Aktif tingkat tinggi

AD FS Authentication Flow

  1. Layanan Federasi Direktori Aktif menerima permintaan autentikasi dari klien.

  2. Layanan Federasi Direktori Aktif memvalidasi ID klien dalam permintaan autentikasi dengan ID klien yang diperoleh selama pendaftaran klien dan sumber daya di Layanan Federasi Direktori Aktif. Jika menggunakan klien rahasia, maka Layanan Federasi Direktori Aktif juga memvalidasi rahasia klien yang disediakan dalam permintaan autentikasi. Layanan Federasi Direktori Aktif juga memvalidasi URI pengalihan Klien.

  3. Layanan Federasi Direktori Aktif mengidentifikasi sumber daya yang ingin diakses klien melalui parameter sumber daya yang diteruskan dalam permintaan autentikasi. Jika menggunakan pustaka klien MSAL, parameter sumber daya tidak dikirim. Sebaliknya url sumber daya dikirim sebagai bagian dari parameter cakupan: cakupan = [url sumber daya]/[nilai cakupan misalnya, openid].

    Jika sumber daya tidak diteruskan menggunakan parameter sumber daya atau cakupan, Layanan Federasi Direktori Aktif akan menggunakan urn sumber daya default:microsoft:userinfo yang kebijakannya (misalnya, MFA, penerbitan, atau kebijakan otorisasi) tidak dapat dikonfigurasi.

  4. Layanan Federasi Direktori Aktif berikutnya memvalidasi apakah klien memiliki izin untuk mengakses sumber daya. Layanan Federasi Direktori Aktif juga memvalidasi apakah cakupan yang diteruskan dalam permintaan autentikasi cocok dengan cakupan yang dikonfigurasi saat mendaftarkan sumber daya. Jika klien tidak memiliki izin atau cakupan yang tepat tidak dikirim dalam permintaan autentikasi, alur autentikasi dihentikan.

  5. Setelah izin dan cakupan divalidasi, Ad FS mengautentikasi pengguna menggunakan metode autentikasi yang dikonfigurasi.

  6. Jika metode autentikasi tambahan diperlukan sesuai kebijakan sumber daya atau kebijakan autentikasi global, Layanan Federasi Direktori Aktif memicu autentikasi tambahan.

  7. Layanan Federasi Direktori Aktif menggunakan Azure MFA atau MFA pihak ke-3 untuk melakukan autentikasi.

  8. Setelah pengguna diautentikasi, Ad FS menerapkan aturan klaim (menentukan klaim yang dikirim ke sumber daya sebagai bagian dari token keamanan) dan kebijakan kontrol akses (menentukan bahwa pengguna telah memenuhi kondisi yang diperlukan untuk mengakses sumber daya).

  9. Selanjutnya, Layanan Federasi Direktori Aktif menghasilkan Token Akses dan Refresh. Layanan Federasi Direktori Aktif juga menghasilkan token ID.

  10. Jika cakupan = allatclaims disertakan dalam permintaan autentikasi, token ID disesuaikan untuk menyertakan klaim dalam token akses berdasarkan aturan klaim yang ditentukan.

  11. Setelah token yang diperlukan dihasilkan dan disesuaikan, Layanan Federasi Direktori Aktif merespons klien termasuk token. Hanya jika permintaan autentikasi menyertakan cakupan = openid, token ID disertakan dalam respons. Klien selalu dapat memperoleh autentikasi posting token ID menggunakan titik akhir token.

Jenis pustaka

Dua jenis pustaka digunakan dengan LAYANAN Federasi Direktori Aktif:

  • Pustaka klien: Klien asli dan aplikasi server menggunakan pustaka klien untuk memperoleh token akses untuk memanggil sumber daya seperti API Web. Microsoft Authentication Library (MSAL) adalah pustaka klien terbaru dan direkomendasikan saat menggunakan LAYANAN Federasi Direktori Aktif 2019. Pustaka Autentikasi Direktori Aktif (ADAL) direkomendasikan untuk Layanan Federasi Direktori Aktif 2016.

  • Pustaka middleware server: Aplikasi web menggunakan pustaka middleware server untuk masuk pengguna. API Web menggunakan pustaka middleware server untuk memvalidasi token yang dikirim oleh klien asli atau oleh server lain. OWIN (Open Web Interface for .NET) adalah pustaka middleware yang direkomendasikan.

Menyesuaikan Token ID (klaim tambahan dalam Token ID)

Dalam skenario tertentu, ada kemungkinan bahwa aplikasi Web (klien) memerlukan klaim tambahan dalam token ID untuk membantu dalam fungsionalitas. Ini dapat dicapai dengan menggunakan salah satu opsi berikut:

Opsi 1: Harus digunakan saat menggunakan klien publik dan aplikasi web tidak memiliki sumber daya yang coba diaksesnya. Opsi memerlukan:

  • response_mode ditetapkan sebagai form_post
  • Pengidentifikasi pihak yang mengandalkan (pengidentifikasi API Web) sama dengan pengidentifikasi klien

AD FS Customize Token Option 1

Opsi 2: Harus digunakan ketika aplikasi web memiliki sumber daya yang coba diakses dan perlu meneruskan klaim tambahan melalui token ID. Klien publik dan rahasia dapat digunakan. Opsi memerlukan:

  • response_mode ditetapkan sebagai form_post

  • KB4019472 diinstal di server AD FS Anda

  • Lingkup allatclaims yang ditetapkan ke pasangan klien – RP. Anda dapat menetapkan cakupan dengan menggunakan cmdlet PowerShell Grant-ADFSApplicationPermission (Gunakan Set-AdfsApplicationPermission jika sudah diberikan sekali) seperti yang ditunjukkan dalam contoh di bawah ini:

    Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"

AD FS Customize Token Option 2

Untuk lebih memahami cara mengonfigurasi Aplikasi Web di Layanan Federasi Direktori Aktif untuk memperoleh token ID yang disesuaikan, lihat Menyesuaikan klaim yang akan dikeluarkan di id_token saat menggunakan OpenID Koneksi atau OAuth dengan LAYANAN Federasi Direktori Aktif 2016 atau yang lebih baru.

Keluar tunggal

Hasil keluar tunggal mengakhiri semua sesi klien menggunakan ID sesi. Layanan Federasi Direktori Aktif 2016 dan yang lebih baru mendukung akses menyeluruh untuk OpenID Koneksi/OAuth. Untuk informasi selengkapnya, lihat Akses menyeluruh untuk OpenID Koneksi dengan Layanan Federasi Direktori Aktif.

Titik Akhir Layanan Federasi Direktori Aktif

Titik Akhir Layanan Federasi Direktori Aktif Deskripsi
/authorize Layanan Federasi Direktori Aktif mengembalikan kode otorisasi yang dapat digunakan untuk mendapatkan token akses
/token Layanan Federasi Direktori Aktif mengembalikan token akses yang dapat digunakan untuk mengakses sumber daya (API Web)
/userinfo Layanan Federasi Direktori Aktif mengembalikan klaim tentang pengguna yang diautentikasi
/devicecode Layanan Federasi Direktori Aktif mengembalikan kode perangkat dan kode pengguna
/logout Layanan Federasi Direktori Aktif mengeluarkan pengguna
/kunci Kunci publik Layanan Federasi Direktori Aktif yang digunakan untuk menandatangani respons
/.well-known/openid-configuration Layanan Federasi Direktori Aktif mengembalikan metadata Koneksi OAuth/OpenID