Bagikan melalui

Skenario yang tidak didukung

  • Artikel

Karena berbagai alasan, Windows Communication Foundation (WCF) tidak mendukung beberapa skenario keamanan tertentu. Misalnya, Windows XP Home Edition tidak menerapkan protokol autentikasi SSPI atau Kerberos, dan oleh karena itu WCF tidak mendukung operasi layanan dengan autentikasi Windows pada platform tersebut. Mekanisme autentikasi lainnya, seperti nama pengguna/kata sandi dan autentikasi terintegrasi HTTP/HTTPS didukung saat menjalankan WCF di bawah Windows XP Home Edition.

Skenario peniruan

Identitas yang ditiru mungkin tidak mengalir ketika klien melakukan panggilan asinkron

Ketika klien WCF melakukan panggilan asinkron ke layanan WCF menggunakan autentikasi Windows di bawah peniruan identitas, autentikasi mungkin terjadi dengan identitas proses klien alih-alih identitas yang ditiru.

WCF tidak mendukung peniruan identitas dan InvalidOperationException dilepaskan ketika kondisi berikut ada:

  • Sistem operasi Windows XP.

  • Mode autentikasi menghasilkan identitas Windows.

  • Properti Impersonation dari OperationBehaviorAttribute diatur ke Required.

  • Token konteks keamanan (security context token atau SCT) berbasis status dibuat (secara default, pembuatan dinonaktifkan).

SCT berbasis status hanya dapat dibuat menggunakan pengikatan khusus. Untuk mengetahui informasi selengkapnya, lihat Cara: Membuat Token Konteks Keamanan untuk Sesi Aman. Dalam kode, token diaktifkan dengan membuat elemen pengikatan keamanan (baik SymmetricSecurityBindingElement atau AsymmetricSecurityBindingElement) menggunakan metode SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) atau SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) dan mengatur requireCancellation parameter ke false. Parameter mengacu pada penembolokan SCT. Mengatur nilai ke false mengaktifkan fitur SCT berbasis status.

Atau, dalam konfigurasi, token diaktifkan dengan membuat <customBinding>, lalu menambahkan elemen<security>, dan mengatur atribut authenticationMode ke SecureConversation dan atribut requireSecurityContextCancellation ke true.

Catatan

Persyaratan sebelumnya bersifat spesifik. Misalnya, CreateKerberosBindingElement membuat elemen pengikatan yang menghasilkan identitas Windows, tetapi tidak membuat SCT. Oleh karena itu, Anda dapat menggunakannya dengan opsi Required pada Windows XP.

Kemungkinan konflik ASP.NET

WCF dan ASP.NET dapat mengaktifkan atau menonaktifkan peniruan. Ketika ASP.NET meng-hosting aplikasi WCF, konflik mungkin ada antara pengaturan konfigurasi WCF dan ASP.NET. Jika terjadi konflik, pengaturan WCF lebih diutamakan, kecuali properti Impersonation diatur ke NotAllowed, dalam hal ini pengaturan peniruan ASP.NET lebih diutamakan.

Beban assembly mungkin gagal dalam peniruan

Jika konteks yang ditiru tidak memiliki hak akses untuk memuat assembly dan jika ini adalah pertama kalinya runtime bahasa umum (common language runtime atau CLR) mencoba memuat assembly untuk AppDomain tersebut, AppDomain menembolok kegagalan tersebut. Upaya berikutnya harus memuat assembly (atau semua assembly) tersebut gagal, bahkan setelah mengembalikan peniruan, dan bahkan jika konteks yang dikembalikan memiliki hak akses untuk memuat assembly. Ini karena CLR tidak memasang ulang beban setelah konteks pengguna diubah. Anda harus memulai ulang domain aplikasi untuk memulihkan dari kegagalan.

Catatan

Nilai default untuk properti AllowedImpersonationLevel dari kelas WindowsClientCredential adalah Identification. Dalam kebanyakan kasus, konteks peniruan tingkat-identifikasi tidak memiliki hak untuk memuat assembly tambahan apa pun. Ini adalah nilai default, jadi ini adalah kondisi yang sangat umum untuk diperhatikan. Peniruan tingkat-identifikasi juga terjadi ketika proses peniruan identitas tidak memiliki hak istimewa SeImpersonate. Untuk informasi selengkapnya, lihat Delegasi dan Peniruan Identitas.

Delegasi memerlukan negosiasi kredensial

Untuk menggunakan protokol autentikasi Kerberos dengan delegasi, Anda harus mengimplementasikan protokol Kerberos dengan negosiasi kredensial (terkadang disebut Kerberos "multisesi" atau "multilangkah"). Jika Anda menerapkan autentikasi Kerberos tanpa negosiasi kredensial (terkadang disebut Kerberos "satu kali" atau "sesi tunggal"), pengecualian akan dilemparkan. Untuk informasi selengkapnya tentang cara menerapkan negosiasi kredensial, lihat Kesalahan Autentikasi Debugging Windows.

Kriptografi

SHA-256 hanya didukung untuk penggunaan kunci konten

WCF mendukung berbagai algoritma pembuatan enkripsi dan digest tanda tangan yang dapat Anda tentukan menggunakan rangkaian algoritma dalam pengikatan yang disediakan sistem. Untuk keamanan yang ditingkatkan, WCF mendukung algoritma Secure Hash Algorithm (SHA) 2, khususnya SHA-256, untuk membuat hash digest tanda tangan. Rilis ini mendukung SHA-256 khusus untuk penggunaan kunci konten, seperti kunci Kerberos, dan ketika sertifikat X.509 tidak digunakan untuk menandatangani pesan. WCF tidak mendukung tanda tangan RSA (digunakan dalam sertifikat X.509) menggunakan hash SHA-256 karena kurangnya dukungan saat ini untuk RSA-SHA256 di WinFX.

Hash SHA-256 yang memenuhi FIPS tidak didukung

WCF tidak mendukung hash yang memenuhi SHA-256 FIPS, sehingga suite algoritma yang menggunakan SHA-256 tidak didukung oleh WCF pada sistem ketika penggunaan algoritma yang memenuhi FIPS diperlukan.

Algoritma yang memenuhi FIPS mungkin gagal jika registri diedit

Anda dapat mengaktifkan dan menonaktifkan algoritma yang memenuhi Standar Pemrosesan Informasi Federal (Federal Information Processing Standard atau FIPS) dengan menggunakan snap-in Microsoft Management Console (MMC) Local Security Setting. Anda juga dapat mengakses pengaturan di registri. Namun, perhatikan bahwa WCF tidak mendukung penggunaan registri untuk mengatur ulang pengaturan. Jika nilai diatur ke apa pun selain 1 atau 0, hasil yang tidak konsisten dapat terjadi antara CLR dengan sistem operasi.

Batasan enkripsi AES yang memenuhi FIPS

Enkripsi AES yang memenuhi FIPS tidak berfungsi dalam panggilan balik dupleks di bawah peniruan tingkat identifikasi.

Sertifikat CNG/KSP

Cryptography API: Next Generation (CNG) adalah pengganti jangka panjang untuk CryptoAPI. API ini tersedia dalam kode yang tidak dikelola pada Windows Vista, Windows Server 2008, dan versi Windows yang lebih baru.

.NET Framework 4.6.1 dan versi yang lebih lama tidak mendukung sertifikat ini karena menggunakan CryptoAPI warisan untuk menangani sertifikat CNG/KSP. Penggunaan sertifikat ini dengan .NET Framework 4.6.1 dan versi yang lebih lama akan menyebabkan pengecualian.

Ada dua cara yang mungkin untuk mengetahui apakah sertifikat menggunakan KSP:

  • Lakukan p/invoke dari CertGetCertificateContextProperty, dan periksa dwProvType pada CertGetCertificateContextProperty yang dikembalikan.

  • Gunakan certutil perintah dari baris perintah untuk mengkueri sertifikat. Untuk informasi selengkapnya, lihat Tugas Certutil untuk pemecahan masalah sertifikat.

Keamanan pesan gagal jika menggunakan peniruan ASP.NET dan kompatibilitas ASP.NET diperlukan

WCF tidak mendukung kombinasi pengaturan berikut karena dapat mencegah terjadinya autentikasi klien:

  • Peniruan ASP.NET diaktifkan. Ini dilakukan dalam file Web.config dengan mengatur atribut impersonate dari elemen <identity> ke true.

  • Mode kompatibilitas ASP.NET diaktifkan dengan mengatur aspNetCompatibilityEnabled atribut <serviceHostingEnvironment> ke true.

  • Keamanan mode pesan digunakan.

Solusinya adalah menonaktifkan mode kompatibilitas ASP.NET. Atau, jika mode kompatibilitas ASP.NET diperlukan, nonaktifkan fitur peniruan ASP.NET dan gunakan peniruan yang disediakan WCF sebagai gantinya. Untuk informasi selengkapnya, lihat Delegasi dan Peniruan Identitas.

Kegagalan alamat harfiah IPv6

Permintaan keamanan gagal ketika klien dan layanan berada di komputer yang sama, dan alamat harfiah IPv6 digunakan untuk layanan.

Alamat IPv6 harfiah berfungsi jika layanan dan klien berada di komputer yang berbeda.

Kegagalan pengambilan WSDL dengan kepercayaan gabungan

WCF memerlukan tepat satu dokumen WSDL untuk setiap simpul dalam rantai kepercayaan gabungan. Berhati-hatilah untuk tidak mengatur perulangan saat menentukan titik akhir. Salah satu cara ketika perulangan dapat muncul adalah menggunakan unduhan WSDL dari rantai kepercayaan gabungan dengan dua tautan atau lebih dalam dokumen WSDL yang sama. Skenario umum yang dapat menghasilkan masalah ini adalah layanan gabungan ketika Server Token Keamanan dan layanan dimuat di dalam ServiceHost yang sama.

Contoh situasi ini adalah layanan dengan tiga alamat titik akhir berikut:

  • http://localhost/CalculatorService/service (layanan)

  • http://localhost/CalculatorService/issue_ticket (STS)

  • http://localhost/CalculatorService/mex (titik akhir metadata)

Ini melepaskan pengecualian.

Anda dapat membuat skenario ini berfungsi dengan menempatkan titik akhir issue_ticket di tempat lain.

Atribut impor WSDL dapat hilang

WCF kehilangan jejak atribut pada elemen <wst:Claims> dalam templat RST saat melakukan impor WSDL. Ini terjadi selama impor WSDL jika Anda menentukan <Claims> langsung di WSFederationHttpBinding.Security.Message.TokenRequestParameters atau IssuedSecurityTokenRequestParameters.AdditionalRequestParameters alih-alih menggunakan koleksi jenis klaim secara langsung. Karena impor kehilangan atribut, pengikatan tidak melakukan perjalanan pulang pergi dengan benar melalui WSDL dan karenanya salah di sisi klien.

Perbaikannya adalah memodifikasi pengikatan langsung pada klien setelah melakukan impor.

Lihat juga