Jaga agar pengikatan MEX tidak aman saat mengamankan pengikatan HTTP dengan UsernamePasswordValidator?

Kami menggunakan UsernamePasswordValidator bersama dengan sertifikat untuk mengamankan akses ke layanan WCF kami.

Namun, kebijakan otorisasi khusus yang kami gunakan adalah perilaku SERVICE, bukan perilaku titik akhir, sehingga kebijakan tersebut berlaku untuk semua titik akhir, termasuk titik akhir MEX. Kami ingin dapat membuka dan mengambil referensi layanan menggunakan visual studio tanpa harus mengomentari perilaku layanan setiap saat, tetapi karena titik akhir mex dan wshttp diamankan, kami mendapatkan kesalahan saat melakukan "Tambahkan Referensi Layanan .."

Apakah ada jalan keluarnya?


.net c# wcf wcf-security
person mgerety    schedule 24.06.2009    source sumber

Jawaban (2)


arrow_upward
1
arrow_downward

Apakah Anda menggunakan pengikatan yang sama pada keduanya? Jika demikian, coba 2 pengikatan terpisah - satu untuk titik akhir mex dan satu lagi untuk wshttp:

Jadi untuk layanannya - sesuatu seperti:

<wsHttpBinding><binding name="wsHttpBindingMessageUname">
<security mode="Message">
    <message clientCredentialType="UserName" negotiateServiceCredential="true"
      establishSecurityContext="false" />
</security></binding></wsHttpBinding>

dan untuk titik akhir mex (tanpa keamanan):

<customBinding><binding name="customMex">
<textMessageEncoding>
    <readerQuotas maxDepth="2147483647"
          maxStringContentLength="2147483647"
          maxArrayLength="2147483647"
          maxBytesPerRead="2147483647"
          maxNameTableCharCount="2147483647" />
</textMessageEncoding>
<httpTransport transferMode="Buffered"
               maxReceivedMessageSize="2147483647"
               maxBufferSize="2147483647"/></binding></customBinding>

Titik akhir layanan akan berbentuk seperti:

<endpoint address="" behaviorConfiguration="Server.Services.DefaultEndpointBehavior"  binding="wsHttpBinding" bindingConfiguration="wsHttpBindingMessageUname" name="DefaultHttp" contract="Server.Services.IMyService" listenUriMode="Explicit" />
<endpoint address="mex" binding="customBinding" contract="IMetadataExchange" name="" bindingConfiguration="customMex" listenUriMode="Explicit" />

Dengan pengaturan ini, keamanan untuk mex tidak diterapkan sehingga Anda tidak akan menerima pesan tersebut saat mencoba memperbarui referensi layanan. Entah itu, atau buat pengikatan aman lain yang menggunakan kredensial berbeda, misalnya sertifikat klien di mesin Anda.

Posting MSDN berikut memiliki contohnya dan info lebih lanjut dapat diperoleh ditemukan di blog ini mengenai titik akhir mex yang aman.

person Tanner    schedule 25.06.2009

arrow_upward
0
arrow_downward

Saya pikir dari pertanyaan dia juga mencatat bahwa dia menggunakan Perilaku Layanan, jadi konfigurasi pengikatan tidak akan membuat perbedaan, karena seluruh layanan menggunakan Validator UserNamePassword.

Ada dua hal yang terlintas dalam pikiran di sini.

Hapus pengikatan mex eksplisit dan tambahkan di bawah perilaku layanan

<serviceMetadata httpsGetEnabled="true" />

Atau Pertahankan pengikatan mex, dan aktifkan

<serviceMetadata httpGetEnabled="true" />

CustomUserNameValidator tidak dieksekusi saat meminta Metadata, jadi jika httpsgetenabled tidak aktif, dan Anda memiliki pengikatan mex pada http, setidaknya Anda memerlukan httpGetenabled

person Neil    schedule 25.06.2009
comment
Saya pikir ini masih berfungsi karena semua layanan saya memiliki konfigurasi perilaku tingkat layanan yang menentukan Kredensial layanan: cert & uname/pass. Kemudian pada titik akhir layanan saya mengatur behaviorConfiguration ke perilaku titik akhir kosong (hanya dengan nama, yang mungkin tidak diperlukan - tetapi tidak rusak, jadi tidak diperbaiki), maka titik akhir mex tidak memiliki behaviorConfiguration. - person Tanner; 25.06.2009
comment
Ini seharusnya berfungsi, tetapi nama penggunanya bukan masalahnya, menurut saya itu bukan pengkodean lapisan transport atau lapisan pesan, atau pengikatan yang digunakan. Saya pikir itu fakta yang mex di http ketika layanan mencoba berperilaku seperti https dengan sertifikat adalah pelakunya - person Neil; 25.06.2009