Промежуточная среда веб служб ASP.NET

Метод CreateClientOutputFilter данного расширения создает фильтр SOAP, который будет добавлять информацию о пользователе в заголовок сообщения.

public override SoapFilter CreateClientOutputFilter(
    FilterCreationContext context)
{
    return new UsernameClientFilter(this, credential, context);
}

public override SoapFilter CreateClientInputFilter(
    FilterCreationContext context)
{    
    return null;
}

public override SoapFilter CreateServiceInputFilter(
    FilterCreationContext context)
{
    return null;
}

public override SoapFilter CreateServiceOutputFilter(
    FilterCreationContext context)
{
    return null;
}
    }

Фильтр наследован от класса SendSecurityFilter и добавляет в сообщение токен с паролем в форме хеша в своем методе SecureMessage.

class UsernameClientFilter : SendSecurityFilter
{
    private UserCredential credential;
        
    public UsernameClientFilter(UsernameClientAssertion assertion, 
        UserCredential credential, FilterCreationContext filterContext)
        : base(assertion.ServiceActor, true, assertion.ClientActor)
    {
        this.credential = credential;
    }

    public override void SecureMessage(SoapEnvelope envelope, 
         Security security)
    {
        UsernameToken userToken = new UsernameToken(credential.Username, 
            credential.Password, PasswordOption.SendHashed);
            
         security.Tokens.Add(userToken);            
     }
 }   
}

Для составления файла с пользователями можно использовать следующую вспомогательную программу.

// AddUser.cs
using System;
using System.IO;
using Seva.WS.Users;

class MainApp
{   
    public static int Main(string[] Args)
    {
        if (Args.Length < 3)
        {
            Console.WriteLine(
                "usage: adduser <users' file> <username> <password> [--hashed]");
            return 1;
        }        
        UsersList users = new UsersList();        
        string fileName = Args[0];               
        
        if (File.Exists(fileName))
        {
            users = UsersList.Load(fileName);
        }
        
        bool hashed = false;
        if (Args.Length==4) 
        {    
            hashed = Args[3]=="--hashed";
        }
        
        users.NewUser(Args[1], Args[2], hashed);                    
        users.Save(fileName);
        return 0;
    }
}

На стороне сервера можно воспользоваться стандартным расширением WSE UsernameOverTransportAssertion без шифрования сообщения, которое будет использовать описанный ранее специальный менеджер пользовательских записей, простейший вариант файла политики wse3policyCache.config указан ниже.

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
    <extension name="usernameOverTransportSecurity" 
	type="Microsoft.Web.Services3.Design.UsernameOverTransportAssertion, Microsoft.Web.Services3, 
	Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <extension name="requireActionHeader"
       type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion,
             Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral,
             PublicKeyToken=31bf3856ad364e35" />
  </extensions>
  <policy name="ServicePolicy">
    <usernameOverTransportSecurity />
    <requireActionHeader />
  </policy>
</policies>

Файл политики клиента при использовании расширения UsernameClientAssertion имеет следующий вид.

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">
  <extensions>
    <extension name="simpleUserName" type="Seva.WS.Users.UsernameClientAssertion,
      Seva.WS.UsersManager, Version=1.0.0.0, Culture=neutral, PublicKeyToken=..."/>
  </extensions>
  <policy name="ClientPolicy">
    <simpleUserName file="user.xml"/>
  </policy>
</policies>

Файл user.xml содержит имя пользователя и пароль клиента веб службы.

<user username="user2" password="222" />

При использовании шифрования сообщений, например, на основе сертификатов X.509 и расширения UsernameForCertificateAssertion использовать описанное расширение клиента UsernameClientAssertion не следует, поскольку при шифровании всего сообщения нет необходимости посылать образ пароля вместо него самого. Поэтому можно использовать расширение стандартное UsernameForCertificateAssertion для клиента и сервера, которое будет использовать созданный менеджер пользователей. Наиболее простой способ конфигурирования политик в таком случае заключается в использование утилиты WseConfigEditor3.exe.

7.6. Выводы по использованию веб служб

Веб службы являются принятым индустриальным стандартом взаимодействия в распределенных системах. Их реализация на платформе .NET позволяет при использовании WSE полностью отделить политику доступа к службе от самого механизма службы. Проанализируем веб службы с точки зрения требований к распределенной системе.

1. Открытость. Веб сервисы построены на общепринятых стандартах и в силу этого являются открытой промежуточной средой. Они могут использоваться практически в любых сетях TCP/IP, в том числе через NAT и межсетевые экраны, поскольку обычно используют стандартный порт протокола HTTP. При необходимости веб службы могут быть использованы поверх различных транспортных протоколов.
2. Масштабируемость, и устойчивость. Веб службы поддерживают только модель единственного вызова, поэтому балансировка нагрузок и обеспечение надежности сервиса может быть организовано путем создания кластера IIS или иными способами, оперирующими только с транспортным протоколом веб служб. Модель единственного вызова позволяет создавать масштабируемые приложения.
3. Безопасность. Поддерживаемый WSE стандарт WS-Security 1.1 позволяет организовать разнообразные способы аутентификации пользователя, совмещенные с шифрованием сообщения и организации списка доступа к сервису.
4. Поддержание логической целостности данных. Недостатком текущей реализации веб служб является отсутствие поддержки в настоящий момент распределенных между несколькими веб службами транзакций. В случае веб служб .NET данная проблема будет, вероятно, решена по мере перехода на .NET Framework 3.0 и WCF.
5. Эффективность (в узком смысле). На передачу и разбор сообщений SOAP тратятся некоторые временные ресурсы, однако это является умеренной платой за открытый и расширяемый характер веб служб.

Все сказанное выше позволяет считать веб сервисы наиболее универсальной, открытой, масштабируемой и надежной технологией построения распределенных систем. Реализация механизма расширений WSE достаточно понятна и проста для использования разработчиком. После повсеместного принятия полного набора стандартов WS-* веб службы будут обладать широкими возможностями поддержки распределенных транзакций. Также определенным недостатком веб служб ASP.NET можно считать отсутствие в настоящий момент поддержки локального взаимодействия, не затрагивающего стек TCP/IP.