Natale

Задача: установить между клиентом и сервисом WCF безопасное соединение на транспортном уровне (с использование сертификата) и при этом применить аутентификацию по протоколу Kerberos.

Решение: кастомная привязка (binding) c параметром authenticationMode, установленным в значение KerberosOverTransport.

<customBinding>
   <binding name="kerberosCustomBinding">
      <security authenticationMode="KerberosOverTransport" />
      <httpsTransport />
   </binding>
</customBinding>

Примечание: при подобной конфигурации необходимо прописать для учетной записи, от которой работает WCF сервис (пул IIS), SPN (Service Principal Name), например, setspn.exe -a http\<serverFQDN> <domain\wcfserviceaccount>. А в конфигурационном файле клиента выставить соответствующие значение (<servicePrincipalName> тэг), например, <servicePrincipalName value="http\<serverFQDN>">, где <serverFQDN> - полное доменное имя сервера, а <domain\wcfserviceaccount> - доменная учетная запись, от имени которой запущен WCF сервис.

Поддержка REST появилась еще в предыдущей версии WCF 3.5, в частности появилась возможность публиковать операции сервиса для вызова по GET/POST (атрибут WebInvoke). Разумеется, только этим поддержка REST не ограничивалось, еще был создан дополнительный модуль - WCF REST Starter Kit, который, к сожалению, не был составной частью .Net Framework.
В версии WCF 4.0 возможности REST программирования уделено не меньше внимания, чем и традиционной SOAP модели, и REST – это теперь полноценная составная часть структуры WCF.

WebGet/WebInvoke - специальные атрибута операции сервиса, которые определяют, что данная операция может быть вызвана по HTTP GET или HTTP POST соответственно, т.е. не требуется формирования SOAP конверта, а достаточно стандартного HTTP запроса. Обычно операция сервиса вызывается с некоторыми входными параметрами, в данном случае входные параметры могут быть переданы либо через URL (query string), либо через тело HTTP запроса (post data). Для удобства извлечения значений входных параметров из URL можно использовать специальную конструкцию – UriTemplate, позволяющую описать структуру и разбор URL, по которому вызвается сервис.

[WebGet(UriTemplate = "Users/{userName}")]   
public User GetUser(string userName)
{   
}
[WebInvoke(UriTemplate = "Tasks/{id}", Method = "PUT")]  
public Task UpdateTask(string id, Task task)  
{  
}

В примере операция GetUser публикуется по GET и принимает входной параметр (из URL) userName. Обратите внимание, что преобразование типа входного параметра к srting производится автоматически, т.е. вместо string может быть указан любой другой простой тип, например, int.
Операция UpdateTask публикуется по метод HTTP PUT, с входным параметром id все аналогично вышеописанной ситуации, входной параметр task извлекается из тела (body) HTTP запроса. При необходимости Вы имеете возможность работать с телом HTTP запросом напрямую, для этого в параметрах метода потребуется указать единственный входной параметр типа Steam.

Help-страница – это специальная страница, содержащая информацию о REST WCF сервисе, в частности, название операций, формат запроса/ответа, схемы данных и т.п. (чем-то напоминает WSDL, хотя важно помнить, что это не WSDL). Для созданного WCF REST сервиса подобная страница создается автоматически, при необходимости она может быть кастомизирована.

<configuration>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
    <behaviors>
      <endpointBehaviors>
        <behavior name="HelpBehavior">
          <webHttp helpEnabled="true" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="CounterResource">
        <endpoint behaviorConfiguration="HelpBehavior"
                  binding="webHttpBinding"
                  contract="CounterResource" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

В примере включается автоматическая генерация Help-страницы, в этом случае страница будет доступна по следующему адресу http://server/restwcfservice/help.

Поддержка JSON/JSONP. Помимо XML формата запроса/ответа WCF REST поддерживает и другие форматы, например: JSON, JSONP. Возможно включение и поддержки ATOM, но для этого на текущий момент потребуется небольшая кастомизация. Формат возвращаемых данных клиенту может быть определен автоматически за счет параметра automaticFormatSelectionEnabled, т.е. Вам не потеряется создавать несколько методов или разветвленную логику для того, чтобы выдать клиенту ответ в предпочтительном для него формате. Важно, что automaticFormatSelectionEnabled применяется к исходящему запросу, т.е. на данный момент ограничить входящие запросы конкретным форматом (JSON или XML) нельзя, запрос в любом формате будет принят сервисом. Логика автоматического выбора формата ответа достаточно проста и логична:

1. Анализируется HTTP Accept заголовок HTTP запроса. Если HTTP Accept отсутствует, то переходим к следующему пункту.
2. Анализируется content-type запроса. Если тело HTTP запроса отсутствует (пустое) или content-type имеет поддерживаемое значение, то переходим к следующему пункту.
3. Ответ выдается в формате по умолчанию для операции.

<configuration>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
    <behaviors>
      <endpointBehaviors>
        <behavior name="HelpBehavior">
          <webHttp helpEnabled="true" />
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <services>
      <service name="CounterResource">
        <endpoint behaviorConfiguration="HelpBehavior"
                  binding="webHttpBinding"
                  contract="CounterResource" />
      </service>
    </services>
  </system.serviceModel>
</configuration>

В примере в конфигурационном файле включается опция автоматического определения формата ответа REST сервиса.

Возможность WCF автоматического формирования ответа в приемлемом для клиента формате очень удобна, и не менее удобная и полезна поддержка JSONP формата, которая включена в WCF REST. В чем отличие JSON от JSONP? JSONP (JSON Padding) является расширением JSON, когда имя функции обратного вызова указывается в качестве входного аргумента [wiki]. JSOPN используется для кросс доменных вызовов, см. JSONP & JSONPP.

WebFaultException - это специальный класс для возврата ошибки (exception) клиенту. WebFaultException наследуется от стандартного FaultException, который определяет формат SOAP исключения. Т.к. REST сервис – это не стандартный SOAP сервис, то и информирование клиента об исключение должно производиться иначе, т.к. SOAP-исключение, обернутое в SOAP конверт, клиент просто не распознает. Поэтому для REST сервисов используется WebFaultException. Отличительной особенностью WebFaultException является то, что ошибка возвращается клиенту в приемлемом для него формате, т.е. если входной запрос пришел в формате JSON, то и информация об ошибке/исключении так же возвратится в формате JSON. WebFaultException помимо описания ошибки имеет и еще одно поле (которое отсутствует в SOAP FaultException) – это статус HTTP (HttpStatusCode), т.к. для REST это важно.

if (user == null) 
{ 
	throw new WebFaultException<string>( 
            string.Format("There is no user with the userName &apos;{0}&apos;.", userName), 
            HttpStatusCode.NotFound); 
}

В примере на клиента возвращается текст ошибки и HTTP статус NotFound.

ASP.NET Routing. WCF REST сервисы поддерживает стандартный ASP.NET Routing (для этого режим совместимость с ASP.NET - aspnetcompatibilityenabled - должен быть включен в конфигурационном файле).
Маршрутизация ASP.NET позволяет использовать URL-адреса, не сопоставляемые с определенными файлами на веб-узле. Подробнее о маршрутизации ASP.NET можно прочесть в статье "Маршрутизация ASP.NET".

private void RegisterRoutes(RouteCollection routes)
{
    routes.Add(new ServiceRoute("Customers", new WebServiceHostFactory(), typeof(Service))); 
}

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true">
    <add name="UrlRoutingModule
     type="System.Web.Routing.UrlRoutingModule, System.Web />
  </modules>
  <handlers>
    <add name="UrlRoutingHandler" path="UrlRouting.axd"	preCondition="integratedMode" verb="*" />   
  </handlers>
</system.webServer>

В примере для WCF REST сервиса подключается в web.config модуль ASP.NET Routing – UrlRoutingModule, а так же в методе RegisterRoutes опредеяются правила маршрутизации (с входным запросом по URL http://server/wcfrestservice/customers сопоставляется операция REST сервиса).

Кэширование. WCF REST сервисы поддерживает стандартный механизм кэширования ASP.NET (для этого режим совместимость с ASP.NET - aspnetcompatibilityenabled - должен быть включен в конфигурационном файле). Для определения параметров кэширования исходящего ответа к операции добавляется атрибут AspNetCacheProfile, в котором указывается имя профиля кэширования, тогда как сам профиль определяется в web.config. Следующие типы кэширования поддерживаются: Any | Client | Downstream | Server | None | ServerAndClient. Интересными являются следующие:

• Client – кэширование данных на стороне клиента, т.е. кэшируемые данные не разделяемые;
• Server – кэширование данных на стороне сервера, т.е. кэшируемые данные разделяемые;
• Downstream - кэширование данных на стороне, например, прокси-сервера.

[AspNetCacheProfile("CacheFor60Seconds")]
[WebGet(UriTemplate=XmlItemTemplate)]
public Counter GetItemInXml()
{
    return HandleGet();
}

<configuration>
  <system.web>
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
        <add name="CacheFor60Seconds" duration="60" varyByParam="format" />
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
  </system.web>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
  </system.serviceModel>
</configuration>

В примере устанавливается режим совместимости с ASP.NET, а так же режим кэширования: данные кэшируются на сервере (по умолчанию), данные актуальны в течение одной минуты и зависят от входящего формата запросам, т.е. для JSON формата входящего запроса кэшируется один ответа, а для XML – другой.

Веб-каст с примерами по обсуждаемым возможностям можно найти на портале TechDays.ru - "WCF 4.0 в примерах. Часть 2.".

Недавно ко мне поступил следующий вопрос: «При запуске приложения под IE в темповой папке начинают появляться XPC….tmp файлы размером точно 20 М на каждый вызов метода сервиса. При исследовании причины выяснилось, что они появляются только тогда, когда в контракте службы используются пользовательские типы. В процессе работы временные файлы постепенно удаляются. Отсюда возникает вопрос: можно - ли как-то влиять на создание этих файлов, их более оперативное удаление (например, сразу же после закрытия канала) или их размер?»

В ходе анализа были выполнены следующие действия:

1. Включение мониторинга информации о создании файлов, в частности в директории %localappdata% \Temp, подтвердило, что в данной директории создаются временные файлы с именем XCP*.tmp, где * - уникальная последовательность цифр.
2. Создано аналогичное WPF приложение. С его помощью не удалось воспроизвести проблему.
3. Утилитой ProcMon выполнен мониторинг временных файлов, создающихся Internet Explorer.

Причина: использование GZip сжатия HTTP потока в Silverlight.

Пути решения:

1. Периодически выполнять прямой вызов GC.Collect() в Вашем приложении. Например, этот вызов может зависеть таймера, количества выполненных запросов и т.п.
2. Отключить GZip сжатие для HTTP ответов.
3. В Silverlight 4.0 можно так же установить параметр AllowReadStreamBuffering в значение false.

При написании данной заметки обнаружила недавно появившуюся статью в Knowledge Base - "PRB:Silverlight application creates large temporary files when making calls to WebServices", в которой причины возникновения данного поведения описаны более подробно.

Постановка задачи следующая – опросить программно Active Directory из инсталлятора WinPE. На первый взгляд задача выглядит очень простой, но в WinPE отсутствует, например, поддержка ADSI (Active Directory Service Interfaces). ADSI представляет собой набор COM-интерфейсов для доступа к функциям служб каталогов. У WinPE есть и другие особенности, поэтому начнем с «теории».

WinPE – средства предустановки, это минимальная версия операционной системы Win32 с ограниченными службами, построенная на ядре Windows. Она используется для подготовки компьютера к установке Windows, копирования образа Windows с сетевого файлового сервера и запуска установки Windows.

Среда Windows PE не предназначена для использования в качестве основной операционной системы на компьютере - она служит в качестве изолированной среды предустановки и является встроенным элементом других средств установки и восстановления системы, например программы установки для Windows 7, служб развертывания Windows (Windows DS), пакета средств развертывания операционной системы (OS) сервера SCCM и среды восстановления Windows (Windows RE).

На данный момент последняя версия WinPE – это WinPE 3.0, построенная на ядре Windows 7. Подробнее о WinPE можно прочитать в стать "Что такое Windows РЕ?".

WinPE имеет определенные ограничения, в частности:

• для минимизации размера среды Windows PE в нее включен только ограниченный набор интерфейсов программирования Win32;
• среда Windows PE не поддерживает оболочку Microsoft .NET или среду CLR.

Образ WinPE может быть кастомизирован. Это означает, что в него может быть добавлена поддержка:

• пользовательских скриптов;
• разрешенных дополнительных пакетов, расширяющих стандартную функциональность WinPE.

Для получения более подробной информации смотрите стать "Краткое руководство: создание пользовательского образа Windows PE", "Добавление специального сценария в образ Windows PE" и "Добавление пакета в образ Windows PE".

Из возможностей кастомизации нам с Вами могут быть интересны следующие:

• пакет WinPE-HTA - это поддержка HTML-приложений, позволяющая создавать приложения с графическим интерфейсом пользователя, используя обработчик сценариев Internet Explorer и службы HTML;
• пакет WinPE-Scripting - это поддержка сервера сценариев Windows (WSH), позволяющая производить пакетную обработку файлов с помощью объектов сценариев WSH.

Стоит отметить, что теперь (WinPE 3.0) пакет WinPE-XML входит в базовый файл boot.wim. WinPE-XML - это поддержка программы разбора Microsoft XML (MSXML).

Теперь, когда мы больше знаем о возможностях WinPE, можем предложить следующий вариант решения поставленной задачи:

1. Перенос логики обращения к Active Directory на сторону выделенного сервера приложений. Т.к. на стороне сервера приложений нет ограничений по использованию .Net, то создадим WCF сервис, решающий эту задачу. Для этого воспользуемся пространством имен System.DirectoryServices.AccountManagement (API AccountManagement), которое доступно в .Net 3.5. System.DirectoryServices.AccountManagement пришло на смены System.DirectoryServices, использовавшемуся в .Net 2.0.
2. Использование MSXML для взаимодействия с WCF сервисом: формирование SOAP запроса и получение/разбор SOAP ответа. Для этого будем использовать объект ServerXMLHTTP. ServerXMLHTTP поддерживает как GET, так и POST.
3. Организация общения через SSL (безопасность на уровне транспорта). С бизнес точки зрения это необходимо, т.к. может WCF сервис может выполнять различные операции, например, некоторые из которых могут требовать аутентификации или принимать в качестве параметров конфиденциальные данные. С точки зрения технической - организовать общение по SSL в данном случае будет проще, чем через безопасность на уровне сообщений (WS-Security), т.к. нам придется работать с SOAP практически напрямую. Примечание: в случае, если шифрование не требуется, то можно вообще обойтись не SOAP WCF сервисом, а REST WCF сервисом, что будет еще проще.

Код на стороне WCF сервиса

[ServiceContract]
public interface IActiveDirectory
{
    [OperationContract, WebInvoke(Method = "POST", BodyStyle = WebMessageBodyStyle.Bare)]
    bool ValidateCredentials(Stream stream);
}

public bool ValidateCredentials(Stream stream)
{
    StreamReader reader = null;
    try
    {
        reader = new StreamReader(stream);
        NameValueCollection values = HttpUtility.ParseQueryString(reader.ReadToEnd(), Encoding.UTF8);
        PrincipalContext pc = new PrincipalContext(ContextType.Domain, values["domain"]);
        return pc.ValidateCredentials(values["username"], values["password"]);
    }
    catch (System.Exception ex)
    {
        throw ex;

    }
    finally
    {
        if (reader != null)
            reader.Close();
    }
}

Код на стороне WinPE

Function ValidateCredentialsPOST(username, password, domain)
    Dim srvXmlHttp, docXML
    Set srvXmlHttp = CreateObject ("MSXML2.ServerXMLHTTP.6.0")
    srvXmlHttp.setoption(2) = 13056 
    srvXmlHttp.Open "POST","https://<AppServerUrl>/<WcfServiceFile.svc>/ValidateCredentials", False
    srvXmlHttp.setRequestHeader "CharSet", "UTF-8"
    srvXmlHttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
    srvXmlHttp.Send "username=" & escape(username) & "&password=" & escape(password) & "&domain=" & escape(domain)
    Set docXML = CreateObject("MSXML2.DOMDocument.6.0")
    docXML.LoadXML (srvXmlHttp.ResponseXML.XML)
    ValidateCredentialsPOST = docXML.text
End Function

Обратите внимание на строку srvXmlHttp.setoption(2) = 13056. Она необходима, чтобы принять SSL сертификат сервера приложений, т.к. игнорировать ошибка проверки подлинности сертификата. А так же на функцию escape, которая необходима для кодирования символов передаваемых параметров.