SSL WCF с персонализирано обвързване

Някой някога опитвал ли е да използва персонализирано обвързване със SSL в WCF уеб услуга? Виждал съм редица примери как да направя това с basicHttpBinding и wsHttpBinding, но еквивалентът винаги се проваля за customBinding. По-конкретно това, с което работя в момента (най-успешната конфигурация досега) изглежда по следния начин:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true">
    </serviceHostingEnvironment>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceBehavior">
          <serviceMetadata httpsGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <bindings>
      <customBinding>
        <binding name="binaryHttps">
          <binaryMessageEncoding />
          <httpsTransport />
        </binding>
      </customBinding>
    </bindings>
    <services>
      <service behaviorConfiguration="MyServiceBehavior" name="MyService">
        <host>
          <baseAddresses>
            <add baseAddress="https://(myserver)/"/>
          </baseAddresses>
        </host>
        <endpoint address=""
      binding="customBinding" bindingConfiguration="binaryHttps"
      contract="MyService" />
        <endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
      </service>
    </services>
  </system.serviceModel>

Това всъщност ни позволява да осъществим достъп до услугата от мрежата, да получим нейния WSDL и да добавим препратка към услуга във визуално студио, но когато всъщност се опитаме да я използваме на живо в нашето приложение silverlight-3, тя просто си стои там и чака отговор за неопределено време и никога не изтича. Всъщност в крайна сметка ми създава проблеми с ниска памет след известно време на моята машина (с 6 GB памет). Странното е, че всичко това работи (и все още работи) перфектно в средата за разработка (използвайки стриктно хостовете на VS приложения), едва когато се опитахме да го внедрим на действителен сървър с истински SSL сертификат, всички тези проблеми изскочил.

Търсих доста изчерпателно решение на този проблем, но досега не намерих нищо и опитах почти всичко - Има ли някой там, който се е сблъсквал с това преди и го е заобиколил?


person user138420    schedule 15.07.2009    source източник


Отговори (2)


Оказва се, че проблемът изобщо не е с нашия web.config, а с проблем с IIS 7 и Wildcard SSL сертификати.

А именно, IIS 7 не ви позволява да посочите името на хоста, когато обвързвате IP към SSL връзка и сертификат. Предполагам, че това е така, защото очаква SSL сертификат без заместващ знак, от който може да извлече изричното име на хост. Това, което в крайна сметка трябваше да направим, беше да влезем във файла applicationHost.config в {WindowsDir}\{System32}\{Inetsrv}\{config} и да намерим записа с обвързания IP адрес на нашата уеб услуга и да го променим изрично на (ip ):(име на хост). След това дори беше показан правилно в GUI за конфигуриране на IIS.

След като направихме това, трябваше напълно да изключим всички канали освен SSL на всичките ни сървъри и всичко работеше прекрасно.

Слава богу, това свърши!

person user138420    schedule 15.07.2009

AFAIK, използването на SSL има проблем с производителността. Ние използваме WCF behiovr, за да извършим удостоверяването. Начинът, който използваме, е този Silverlight => ASP.NET => WCF. Конфигурирахме поведението на крайната точка както в Silverlight, така и в WCF. Всеки път, когато се обаждаме на услугата, предаваме токена за удостоверяване.

Искате да кажете, че можете да използвате персонализирано обвързване в ClientConfig на Silverlight?

person Michael Sync    schedule 15.07.2009
comment
Е, ние правим обвързването в код в библиотека Silverlight 3, а не във файла ClientConfig, но да, всичко работи добре на локалната машина. Едва при внедряването имаше проблеми. - person user138420; 15.07.2009
comment
И, само за да потвърдя, успях да накарам услугата да работи перфектно с персонализирано обвързване на самостоятелния сървър в http режим, но това няма да го намали за нашето приложение. Проблемът се появява, когато се опитате да превключите към https. - person user138420; 15.07.2009