Konfigurasikan autentikasi tanpa sertifikat dengan Microsoft. Identity.Web

Artikel ini memperlihatkan kepada Anda cara mengonfigurasi autentikasi tanpa sertifikat sehingga aplikasi Anda mengautentikasi dengan Microsoft Entra ID tanpa mengelola sertifikat atau rahasia klien. Aplikasi Anda menggunakan Federated Identity Credential (FIC) yang didukung oleh identitas terkelola Azure untuk mendapatkan token, yang menghilangkan rotasi kredensial, mengurangi penyebaran rahasia, dan menyederhanakan penyebaran Azure.

Microsoft. Identity.Web mendukung autentikasi tanpa sertifikat melalui jenis sumber kredensial SignedAssertionFromManagedIdentity, tersedia di versi 2.12.0 dan yang lebih baru.

Memahami autentikasi tanpa sertifikat

Bagian ini menjelaskan cara kerja autentikasi tanpa sertifikat dan kapan menggunakannya.

Secara tradisional, aplikasi klien rahasia membuktikan identitas mereka untuk Microsoft Entra ID dengan menyajikan rahasia klien atau sertifikat. Kedua pendekatan mengharuskan Anda mengelola siklus hidup kredensial—memutar rahasia sebelum kedaluwarsa, memperbarui sertifikat, dan menyimpannya dengan aman.

Federated Identity Credentials (FIC) mengubah model ini. Dengan FIC, Anda mengonfigurasi hubungan kepercayaan antara pendaftaran aplikasi dan Identitas Terkelola. Saat aplikasi Anda perlu mengautentikasi:

Microsoft. Identity.Web meminta token dari titik akhir Identitas Terkelola pada host Azure.
Pustaka menggunakan token Identitas Terkelola sebagai pernyataan yang ditandatangani untuk mengautentikasi dengan Microsoft Entra ID.
Microsoft Entra ID memvalidasi pernyataan yang ditandatangani terhadap konfigurasi kredensial federasi pada pendaftaran aplikasi.
Microsoft Entra ID mengeluarkan token akses untuk sumber daya yang diminta.

Hasilnya adalah penyebaran bebas kredensial sepenuhnya di mana tidak ada rahasia atau sertifikat dalam konfigurasi, kode, atau variabel lingkungan Anda.

Pilih pendekatan autentikasi yang tepat

Tabel berikut ini membantu Anda memutuskan kapan autentikasi tanpa sertifikat adalah pilihan yang tepat.

Skenario	Pendekatan yang disarankan
Aplikasi berjalan pada Azure dan Anda menginginkan manajemen kredensial nol	Tanpa sertifikat dengan FIC
Aplikasi berjalan di Azure tetapi perlu mendukung fallback lokal	Kredensial berbasis sertifikat dengan FIC sebagai utama
Aplikasi berjalan di luar Azure (lokal, cloud lainnya)	Sertifikat atau rahasia klien
Pengembangan dan pengujian pada komputer lokal	Kunci rahasia atau sertifikat klien dari penyimpanan lokal

Prasyarat

Verifikasi bahwa Anda memiliki sumber daya dan alat berikut sebelum memulai:

Langganan Azure. Jika Anda tidak memilikinya, buat akun gratis.
Pendaftaran aplikasi di Microsoft Entra ID dengan izin API yang sesuai untuk skenario Anda.
Managed Identity di Azure—baik yang ditetapkan sistem pada sumber daya komputasi Anda atau yang ditetapkan pengguna sebagai Identitas Terkelola mandiri.
Microsoft. Identity.Web versi 2.12.0 atau yang lebih baru diinstal di proyek Anda.
Sumber daya komputasi Azure yang mendukung Identitas Terkelola, seperti Azure App Service, Azure Kubernetes Service (AKS), Azure Container Apps, atau Azure Virtual Machines.

Langkah 1: Membuat atau mengidentifikasi Identitas Terkelola

Anda dapat menggunakan Identitas Terkelola yang ditetapkan sistem atau ditetapkan pengguna. Jika Anda belum membuatnya, ikuti instruksi untuk skenario Anda.

Opsi A: Gunakan Identitas Terkelola yang ditetapkan sistem

Identitas Terkelola yang ditetapkan sistem terkait dengan siklus hidup sumber daya Azure. Saat Anda mengaktifkan identitas yang ditetapkan sistem pada sumber daya seperti App Service, Azure membuat identitas secara otomatis.

Di portal Azure, navigasikan ke sumber daya komputasi Anda (misalnya, App Service Anda).
Pilih Identitas dari menu navigasi kiri.
Pada tab yang ditetapkan Sistem , atur Status ke .
Pilih Simpan dan konfirmasi tindakan.
Setelah identitas dibuat, salin ID Objek (utama). Anda memerlukan nilai ini saat mengonfigurasi kredensial federasi.

Opsi B: Membuat Identitas Terkelola yang ditetapkan pengguna

Identitas Terkelola yang ditetapkan pengguna adalah sumber daya Azure mandiri yang dapat Anda tetapkan ke satu atau beberapa sumber daya komputasi.

Di portal Azure, cari dan pilih Identitas yang Dikelola.
Pilih Buat.
Pilih Langganan, Grup sumber daya, Wilayah, dan masukkan Nama untuk identitas tersebut.
Pilih Tinjau + buat, lalu Buat.
Setelah penyebaran selesai, buka sumber daya Identitas Terkelola baru.
Salin ID Klien dari halaman Gambaran Umum . Anda memerlukan nilai ini untuk konfigurasi aplikasi Anda.

Langkah 2: Mengonfigurasi kredensial Identitas Federasi di portal Azure

Kredensial Identitas Federasi menetapkan hubungan kepercayaan antara pendaftaran aplikasi Anda dan Identitas Terkelola. Ikuti langkah-langkah ini untuk membuatnya:

Di portal Azure, buka Microsoft Entra ID>Pendaftaran aplikasi.
Pilih pendaftaran aplikasi yang digunakan aplikasi Anda.
Di menu navigasi kiri, pilih Sertifikat & rahasia.
Pilih tab Kredensial Federasi.
Pilih Tambahkan kredensial.
Di bawah Skenario kredensial federasi, pilih Kunci yang dikelola pelanggan atau Penerbit lain (opsi yang tersedia bergantung pada versi portal Anda).

Mengonfigurasikan bidang berikut:

Ladang	Nilai
Penerbit	`https://login.microsoftonline.com/{tenant-id}/v2.0` — Ganti `{tenant-id}` dengan ID penyewa Microsoft Entra Anda.
Pengidentifikasi subjek	ID Objek (utama) dari Identitas Terkelola. Untuk yang ditetapkan oleh sistem, temukan ini di halaman Identitas sumber daya. Untuk pengguna yang ditugaskan, temukan ini di halaman Gambaran Umum Identitas Terkelola di bawah ID Pokok.
Nama	Nama deskriptif, misalnya `fic-managed-identity-prod`.
Audiens	`api://AzureADTokenExchange` (nilai default).

Pilih Tambahkan.

Penting

Pengidentifikasi subjek harus sama persis dengan ID Objek (utama) dari Identitas Terkelola. Ketidakcocokan menyebabkan autentikasi gagal dengan kesalahan AADSTS70021 .

Mengonfigurasi kredensial Federated Identity dengan Azure CLI

Atau, buat kredensial federasi dengan Azure CLI. Perintah berikut membuat kredensial pada pendaftaran aplikasi Anda:

az ad app federated-credential create \
    --id <app-object-id> \
    --parameters '{
        "name": "fic-managed-identity-prod",
        "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
        "subject": "<managed-identity-principal-id>",
        "audiences": ["api://AzureADTokenExchange"],
        "description": "FIC for production managed identity"
    }'

URL pengeluar sertifikat berdasarkan layanan Azure

URL penerbit dalam kredensial federasi bergantung pada layanan Azure yang menghosting aplikasi Anda:

layanan Azure	URL Pengeluar Sertifikat
Azure App Service / Azure Functions	`https://login.microsoftonline.com/{tenant-id}/v2.0`
Azure Container Apps	`https://login.microsoftonline.com/{tenant-id}/v2.0`
Azure Kubernetes Service (AKS)	URL penerbit OIDC untuk kluster Anda (ambil dengan `az aks show --query oidcIssuerProfile.issuerUrl`)
Azure Virtual Machines	`https://login.microsoftonline.com/{tenant-id}/v2.0`

Format pengidentifikasi subjek

Format pengidentifikasi subjek bergantung pada jenis Identitas Terkelola:

Identitas Terkelola yang ditetapkan sistem — Gunakan ID Objek (utama) dari halaman Identitas sumber daya. Ini adalah nilai GUID, misalnya a1b2c3d4-e5f6-7890-abcd-ef1234567890.

Identitas Terkelola yang ditetapkan pengguna — Gunakan ID Utama (juga disebut ID Objek) dari halaman Gambaran Umum sumber daya Identitas Terkelola. Ini juga merupakan nilai GUID.

Nota

Untuk AKS dengan identitas beban kerja, pengidentifikasi subjek menggunakan format yang berbeda: system:serviceaccount:{namespace}:{service-account-name}. Nilai ini harus cocok dengan akun layanan Kubernetes yang digunakan pod Anda.

Langkah 3: Mengonfigurasi aplikasi Anda

Memperbarui appsettings.json

Tambahkan ClientCredentials bagian ke konfigurasi AzureAd Anda. Atur SourceType ke SignedAssertionFromManagedIdentity:

Untuk Identitas Terkelola yang ditetapkan oleh pengguna

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Ganti tempat penampung berikut:

Pengganti sementara	Deskripsi
`YOUR_TENANT_ID`	ID penyewa Microsoft Entra Anda.
`YOUR_CLIENT_ID`	ID Aplikasi (klien) pendaftaran aplikasi Anda.
`USER_ASSIGNED_MSI_CLIENT_ID`	ID Klien identitas terkelola yang ditetapkan pengguna (dari halaman Gambaran Umum identitas).

Untuk Identitas Terkelola yang ditetapkan sistem

Ketika Anda menggunakan Identitas Terkelola yang ditetapkan oleh sistem, hilangkan properti ManagedIdentityClientId. Microsoft. Identity.Web secara otomatis menggunakan identitas host yang ditetapkan sistem:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity"
      }
    ]
  }
}

Mendaftarkan layanan di Program.cs

Tidak ada perubahan kode khusus yang diperlukan dalam konfigurasi startup Anda. Metode pendaftaran standar Microsoft.Identity.Web membaca bagian ClientCredentials secara otomatis.

Contoh berikut mendaftarkan autentikasi untuk aplikasi web yang memasukkan pengguna dan memanggil API hilir:

// For a web app that signs in users and calls downstream APIs
builder.Services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

Contoh berikut mendaftarkan autentikasi untuk API web yang memanggil API hilir:

// For a web API that calls downstream APIs
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddInMemoryTokenCaches();

Contoh berikut mendaftarkan autentikasi untuk aplikasi daemon tanpa interaksi pengguna:

// For a daemon application (no user interaction)
builder.Services.AddAuthentication()
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddTokenAcquisition()
    .AddInMemoryTokenCaches();

Microsoft. Identity.Web mendeteksi jenis sumber SignedAssertionFromManagedIdentity dan menangani pertukaran token secara transparan.

Membandingkan Identitas Terkelola yang ditetapkan sistem dan ditetapkan pengguna

Pilih jenis Identitas Terkelola yang paling sesuai dengan arsitektur Anda. Bagian berikut menguraikan pertukaran-pertukaran.

Identitas Terkelola yang Ditentukan oleh Sistem

Identitas yang ditetapkan sistem dibuat dan dihapus secara otomatis dengan sumber daya Azure miliknya.

Keuntungan:

Tidak ada sumber daya terpisah untuk dikelola—siklus hidup identitas cocok dengan sumber daya komputasi.
Penyiapan lebih sederhana untuk penerapan sumber daya tunggal.
Tidak ManagedIdentityClientId diperlukan dalam konfigurasi.

Considerations:

Anda tidak dapat berbagi identitas di beberapa sumber daya.
Jika Anda menghapus dan membuat ulang sumber daya, identitas berubah—Anda harus memperbarui Kredensial Identitas Federasi.

Terbaik untuk: Penyebaran instans tunggal di mana satu sumber daya komputasi memetakan ke satu pendaftaran aplikasi.

Identitas Terkelola yang Ditetapkan Pengguna

Identitas yang ditetapkan pengguna adalah sumber daya Azure mandiri dengan siklus hidupnya sendiri.

Keuntungan:

Bagikan satu identitas di beberapa sumber daya komputasi (misalnya, beberapa instans App Service di wilayah yang berbeda).
Identitas bertahan secara independen dari siklus hidup sumber daya komputasi.
Siapkan dan konfigurasi sebelumnya sebelum menyebarkan sumber daya komputasi.

Considerations:

Sumber daya Azure tambahan untuk dikelola.
Anda harus menentukan ManagedIdentityClientId dalam konfigurasi.

Terbaik untuk: Penyebaran multi-instans atau multi-wilayah, pola penyebaran biru-hijau, dan skenario di mana sumber daya komputasi sering dibuat ulang.

Menyebarkan ke layanan komputasi Azure

Setelah Mengonfigurasi aplikasi, sebarkan ke layanan komputasi Azure yang mendukung Identitas Terkelola.

Azure App Service

Aktifkan Identitas Terkelola di App Service Anda (lihat Langkah 1).
Sebarkan aplikasi Anda ke App Service menggunakan metode pilihan Anda (Visual Studio, Azure CLI, GitHub Actions).
Pastikan bagian AzureAd dalam konfigurasi yang Anda sebarkan cocok dengan pengaturan di Langkah 3.

Jika Anda menggunakan Identitas Terkelola yang telah ditetapkan pengguna, pastikan untuk menetapkannya pada App Service:

az webapp identity assign \
  --resource-group <resource-group> \
  --name <app-service-name> \
  --identities <managed-identity-resource-id>

Mulai ulang App Service untuk mengambil penetapan identitas.

Azure layanan Kubernetes (AKS)

Untuk AKS, gunakan identitas beban kerja untuk mengaitkan akun layanan Kubernetes dengan Identitas Terkelola. Selesaikan langkah-langkah berikut:

Aktifkan fitur identitas beban kerja pada kluster AKS Anda:

az aks update \
  --resource-group <resource-group> \
  --name <aks-cluster-name> \
  --enable-oidc-issuer \
  --enable-workload-identity

Buat akun layanan Kubernetes yang diannotasikan dengan ID klien Identitas Terkelola:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    azure.workload.identity/client-id: "<USER_ASSIGNED_MSI_CLIENT_ID>"

Buat kredensial federasi yang menghubungkan penerbit OIDC AKS dengan Identitas Terkelola.

Konfigurasikan pod Anda untuk menggunakan akun layanan:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: default
  labels:
    azure.workload.identity/use: "true"
spec:
  serviceAccountName: my-app-sa
  containers:
    - name: my-app
      image: <your-container-image>

Sebarkan pod. Webhook identitas beban kerja menyuntikkan variabel lingkungan yang diperlukan untuk titik akhir token Identitas Terkelola.

Azure Container Apps

Buat atau perbarui Aplikasi Kontainer Anda dengan Identitas Terkelola:

az containerapp identity assign \
  --resource-group <resource-group> \
  --name <container-app-name> \
  --user-assigned <managed-identity-resource-id>

Sebarkan gambar kontainer Anda dengan konfigurasi yang sesuai AzureAd .
Titik akhir token Identitas Terkelola tersedia secara otomatis di dalam kontainer.

Migrasi dari sertifikat ke autentikasi tanpa sertifikat

Jika aplikasi Anda saat ini menggunakan autentikasi berbasis sertifikat, Anda dapat bermigrasi ke autentikasi tanpa sertifikat dengan perubahan konfigurasi minimal.

Menyelesaikan langkah-langkah migrasi

Buat Identitas Terkelola untuk sumber daya komputasi Azure Anda (lihat Step 1).
Tambahkan Kredensial Identitas Federasi ke pendaftaran aplikasi Anda (lihat Langkah 2).

Perbarui konfigurasi Anda untuk menambahkan SignedAssertionFromManagedIdentity kredensial. Anda dapat menyimpan kredensial sertifikat yang ada sebagai fallback selama migrasi:

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_CLIENT_ID",
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      },
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Microsoft. Identity.Web mencoba sumber kredensial secara berurutan. Saat berjalan pada Azure, kredensial pertama (SignedAssertionFromManagedIdentity) berhasil. Jika itu gagal (misalnya, selama pengembangan lokal), pustaka akan menggunakan sertifikat sebagai cadangan.

Menyebarkan dan memvalidasi di lingkungan penahapan sebelum diterapkan ke produksi.
Hapus kredensial sertifikat dari konfigurasi setelah Anda mengonfirmasi bahwa autentikasi tanpa sertifikat berfungsi dalam produksi.
Delete sertifikat dari Azure Key Vault dan pendaftaran aplikasi saat tidak lagi diperlukan.

Membandingkan konfigurasi sebelum dan sesudah

Contoh berikut menunjukkan perubahan konfigurasi dari autentikasi berbasis sertifikat menjadi tanpa sertifikat.

Sebelum (berbasis sertifikat):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "KeyVault",
        "KeyVaultUrl": "https://your-keyvault.vault.azure.net",
        "KeyVaultCertificateName": "your-cert-name"
      }
    ]
  }
}

Setelah (tanpa sertifikat):

{
  "AzureAd": {
    "ClientCredentials": [
      {
        "SourceType": "SignedAssertionFromManagedIdentity",
        "ManagedIdentityClientId": "USER_ASSIGNED_MSI_CLIENT_ID"
      }
    ]
  }
}

Memecahkan masalah kesalahan umum

Gunakan panduan berikut untuk mendiagnosis dan mengatasi masalah dengan autentikasi tanpa sertifikat.

AADSTS70021: Tidak ada catatan identitas federasi yang cocok yang ditemukan

Menyebabkan: Pengidentifikasi subjek dalam Kredensial Identitas Federasi tidak cocok dengan ID objek Identitas Terkelola (utama).

Resolusi:

Di portal Azure, navigasikan ke sumber daya Identitas Terkelola dan salin ID Principal (juga disebut ID Objek) dari halaman Overview.
Navigasi ke pendaftaran aplikasi Sertifikat & rahasiaKredensial Federasi.
Verifikasi bidang Pengidentifikasi subjek sama persis dengan ID utama.
Jika nilai tidak cocok, hapus kredensial dan buat ulang dengan pengidentifikasi subjek yang benar.

AADSTS700024: Pernyataan klien tidak dalam rentang waktu yang valid

Penyebab: Token Identitas Terkelola yang digunakan sebagai pernyataan yang ditandatangani telah kedaluwarsa atau jam sistem tidak sinkron.

Resolusi:

Verifikasi jam sistem pada sumber daya Azure Anda akurat.
Mulai ulang aplikasi untuk memaksa permintaan token Identitas Terkelola baru.
Jika Anda menjalankan dalam kontainer, pastikan jam kontainer disinkronkan dengan host.

ManagedIdentityException: Titik akhir Identitas Terkelola tidak tersedia

Cause: Aplikasi tidak dapat menjangkau Azure Instance Metadata Service (IMDS) atau titik akhir token Identitas Terkelola.

Resolusi:

Konfirmasikan bahwa aplikasi berjalan pada sumber daya komputasi Azure yang mendukung Identitas Terkelola.
Pastikan "Managed Identity" diaktifkan dan ditetapkan ke sumber daya komputasi.
Untuk AKS, pastikan webhook identitas beban kerja sedang berjalan dan pod memiliki anotasi akun layanan yang tepat.
Untuk pengembangan lokal, kesalahan ini diharapkan. Gunakan sumber kredensial fallback (lihat Langkah migrasi).

AADSTS700016: Aplikasi tidak ditemukan di direktori

Penyebab: Elemen ClientId dalam konfigurasi Anda tidak sesuai dengan pendaftaran aplikasi yang valid di penyewa yang ditentukan.

Resolusi:

Verifikasi kecocokan ClientIdID Aplikasi (klien) pendaftaran aplikasi Anda.
Verifikasi TenantId cocok dengan penyewa tempat aplikasi didaftarkan.

Mengaktifkan pengelogan debug

Menyebabkan: Urutan sumber kredensial atau ketidakcocokan konfigurasi dapat menyebabkan pustaka melewati kredensial FIC.

Resolusi:

Aktifkan pengelogan di Microsoft. Identity.Web untuk melihat langkah-langkah akuisisi token terperinci. Kode berikut mengonfigurasi pengelogan tingkat debug untuk pustaka identitas:
```
builder.Services.AddLogging(logging =>
{
    logging.AddConsole();
    logging.SetMinimumLevel(LogLevel.Debug);
    logging.AddFilter("Microsoft.Identity", LogLevel.Debug);
});
```
Tinjau log untuk pesan tentang sumber kredensial mana yang dicoba pustaka dan kesalahan apa pun yang dikembalikan.

Identitas Terkelola yang ditetapkan pengguna tidak diambil

Penyebab: Ketika beberapa Identitas Terkelola yang ditetapkan pengguna diberikan ke sumber daya komputasi, library mungkin menggunakan yang salah jika ManagedIdentityClientId tidak ditentukan.

Resolusi:

Selalu tentukan ManagedIdentityClientId properti saat Anda menggunakan Identitas Terkelola yang ditetapkan pengguna.
Verifikasi apakah ID klien cocok dengan identitas yang Anda konfigurasikan untuk Kredensial Identitas Federasi.

Meninjau manfaat keamanan

Autentikasi tanpa sertifikat dengan FIC memberikan keuntungan keamanan yang signifikan daripada pendekatan berbasis kredensial tradisional:

Tidak ada rahasia untuk bocor

Karena tidak ada file sertifikat, kata sandi PFX, atau rahasia klien yang ada dalam konfigurasi atau artefak penyebaran Anda, tidak ada yang dapat diekstrak oleh penyerang. Bahkan jika penyerang mendapatkan akses baca ke file konfigurasi Anda, penyerang tidak dapat meniru aplikasi Anda dari luar Azure.

Tidak ada rotasi kredensial

Token Identitas Terkelola berumur pendek dan secara otomatis disegarkan oleh platform Azure. Anda tidak perlu menerapkan jadwal rotasi, memantau tanggal kedaluwarsa, atau mengoordinasikan pembaruan kredensial di seluruh penyebaran.

Pengurangan permukaan serangan

Titik akhir token Identitas Terkelola hanya dapat diakses dari sumber daya Azure tertentu tempat identitas ditetapkan. Penyerang tidak dapat menggunakan kredensial dari host, jaringan, atau lingkungan cloud yang berbeda.

Penyederhanaan kepatuhan

Tanpa kredensial berumur panjang, Anda menghilangkan beberapa kategori masalah kepatuhan:

Tidak ada rahasia yang disimpan dalam kontrol sumber, variabel lingkungan, atau file konfigurasi.
Tidak tersedia bahan kunci untuk mengaudit, merevisi, atau mencabut.
Tidak ada infrastruktur sertifikat (CA, proses perpanjangan) untuk dipertahankan.

Pertahanan berlapis

Gabungkan autentikasi tanpa sertifikat dengan fitur keamanan Azure lainnya untuk perlindungan berlapis:

Azure RBAC: Mengontrol identitas mana yang dapat mengakses sumber daya mana.
Akses Bersyarat: Terapkan kebijakan berdasarkan risiko identitas, lokasi, dan status perangkat.
Endpoint Pribadi: Membatasi akses jaringan ke sumber daya Azure.
Microsoft Defender untuk Cloud: Memantau pola autentikasi yang mencurigakan.

Gambaran umum kredensial
Sertifikat
Rahasia klien
dokumentasi identitas terkelola Azure
Dokumentasi Kredensial Identitas Federasi
Repositori GitHub Microsoft.Identity.Web

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2026-04-19

Konfigurasikan autentikasi tanpa sertifikat dengan Microsoft. Identity.Web

Memahami autentikasi tanpa sertifikat

Pilih pendekatan autentikasi yang tepat

Prasyarat

Langkah 1: Membuat atau mengidentifikasi Identitas Terkelola

Opsi A: Gunakan Identitas Terkelola yang ditetapkan sistem

Opsi B: Membuat Identitas Terkelola yang ditetapkan pengguna

Langkah 2: Mengonfigurasi kredensial Identitas Federasi di portal Azure

Mengonfigurasi kredensial Federated Identity dengan Azure CLI

URL pengeluar sertifikat berdasarkan layanan Azure

Format pengidentifikasi subjek

Langkah 3: Mengonfigurasi aplikasi Anda

Memperbarui appsettings.json

Untuk Identitas Terkelola yang ditetapkan oleh pengguna

Untuk Identitas Terkelola yang ditetapkan sistem

Mendaftarkan layanan di Program.cs

Membandingkan Identitas Terkelola yang ditetapkan sistem dan ditetapkan pengguna

Identitas Terkelola yang Ditentukan oleh Sistem

Identitas Terkelola yang Ditetapkan Pengguna

Menyebarkan ke layanan komputasi Azure

Azure App Service

Azure layanan Kubernetes (AKS)

Azure Container Apps

Migrasi dari sertifikat ke autentikasi tanpa sertifikat

Menyelesaikan langkah-langkah migrasi

Membandingkan konfigurasi sebelum dan sesudah

Memecahkan masalah kesalahan umum

AADSTS70021: Tidak ada catatan identitas federasi yang cocok yang ditemukan

AADSTS700024: Pernyataan klien tidak dalam rentang waktu yang valid

ManagedIdentityException: Titik akhir Identitas Terkelola tidak tersedia

AADSTS700016: Aplikasi tidak ditemukan di direktori

Mengaktifkan pengelogan debug

Identitas Terkelola yang ditetapkan pengguna tidak diambil

Meninjau manfaat keamanan

Tidak ada rahasia untuk bocor

Tidak ada rotasi kredensial

Pengurangan permukaan serangan

Penyederhanaan kepatuhan

Pertahanan berlapis

Konten terkait

Saran dan Komentar

Sumber Daya Tambahan: