Системы Foundation
Обеспечение безопасности шины служб .NET
Джувел Лоуи
Код загрузки доступны коллекции кода MSDN
Просмотреть код в интерактивном режиме
Содержание
Настройка проверки подлинности
Проверка подлинности CardSpace
Проверка пароля
Сертификат подлинности
Без проверки подлинности
Перенос безопасности
Защита канала связи
Защита сообщений
Привязка ретрансляции TCP и безопасности передачи
Привязка WS ретрансляции и безопасности передачи
One-Way привязка ретрансляции и безопасности передачи
Оптимизация передачи безопасности
В моей колонке апреля 2009 г. я представил шины служб .NET и описано, как можно использовать ретрансляции привязки для подключения приложения и клиентам через границы сети практически все. Однако если только всем пользователям разрешено для ретрансляции сообщений службы или любая служба может принимать вызовы клиента, служба ретрансляции бы опасно предложения. Необходимо защитить передачи сообщения от клиента к службе через служба ретрансляции. В этом столбце показано, как обеспечить безопасность шины служб .NET и предоставлять некоторые вспомогательные классы и служебные программы для автоматизации многие детали.
Шина служб .NET проходят службу, необходимо всегда получают сам ретранслируемой сообщения. Клиенты, с другой стороны, может или не может проверить подлинность сами. Обычно (и по умолчанию) проверку подлинности клиентов, но ретранслируемой службе может понадобиться waive проверки подлинности клиента шины служб .NET.
Шина служб .NET предлагает три механизма проверки подлинности — CardSpace, пароль или сертификат — и это до решения администратору, чтобы связать эти с помощью страницы решения показано на рис. 1.
.png)
Рисунок 1 Настройка параметров проверки подлинности решения
Единое решение может поддерживать несколько вариантов проверки подлинности, а для каждого параметра администратор может добавлять несколько учетных записей. Например администратор может настроить три пароли, две карты и один сертификат. Представления одного из этих учетных данных, достаточно проверку служба ретрансляции. Кроме того службы и клиента могут использовать различные методы. Например служба может использовать пароль и сертификат клиента.
Настройка проверки подлинности
Перечисления TransportClientCredentialType, показанный здесь, представляет параметры доступных учетных данных:
public enum TransportClientCredentialType
{
CardSpace,
UserNamePassword,
X509Certificate
Unauthenticated,
FederationViaCardSpace,
AutomaticRenewal
}
В TransportClientCredentialType, клиент относится к клиентом шины служб .NET —, то оба клиента и ретранслируемой службы.
Механизм основной проверки подлинности и учетные данные сами настраиваются с помощью поведения конечной точки, называется TransportClientEndpointBehavior, определенные в рис. 2.
На рис. 2 TransportClientEndpointBehavior
public class TransportClientEndpointBehavior : IEndpointBehavior
{
public TransportClientCredentials Credentials
{get;}
public TransportClientCredentialType CredentialType
{get;set;}
}
public class TransportClientCredentials
{
public X509CertificateCredential ClientCertificate
{get;}
public UserNamePasswordCredential UserName
{get;}
}
Использование поведения конечной точки (в противоположность режиму поведение службы) предоставляет два преимущества. Во-первых размещения службы можно выбрать механизм проверки подлинности для каждой конечной точки. Во-вторых поведение конечной точки обеспечивает унифицированную модель программирования для клиента и службы, поскольку клиент имеет только поведения конечной точки.
Проверка подлинности CardSpace
CardSpace — это тип учетных данных по умолчанию, используемые всеми привязками ретрансляции. Когда клиент или узел использует CardSpace проверки подлинности, пользователю предлагается для обеспечения карту на открытие узла или прокси-сервера. После пользователь предоставляет карты, он входит в сообщении запроса подключения служба ретрансляции. Очевидно, что такой подход лучше всего подходит для интерактивных приложений. Эти запросы, однако будет раздражать пользователя Если они возникают каждый раз, когда пользователь открывает новый прокси или узла. К счастью учетные данные кэшируются в домене приложения, и пользователю не предлагается повторно, пока он или она обращается к тот же адрес конечной точки.
Проверка пароля
Как проверка подлинности CardSpace проверки подлинности пароля подходит для интерактивного приложения, обычно в сочетании с диалоговое окно входа. Однако нет необходимости предложить пользователю ввести имя пользователя поскольку, всегда является имя решения. После пользователь предоставляет пароль, необходимо программно TransportClientEndpointBehavior предоставить имя решения и пароль.
На стороне главного приложения необходимо создать новый объект TransportClientEndpointBehavior а для свойства CredentialType TransportClientCredentialType.UserNamePassword. Свойство Credentials предоставляются учетные данные сами по себе. Можно затем добавить это поведение каждой конечной точки узел, использующий службу ретрансляции, как показано на рис. 3.
На рисунке 3 Назначение узла с помощью пароля решений
TransportClientEndpointBehavior behavior =
new TransportClientEndpointBehavior();
behavior.CredentialType = TransportClientCredentialType.UserNamePassword;
behavior.Credentials.UserName.UserName = "MySolution";
behavior.Credentials.UserName.Password = "MyPassword";
ServiceHost host = new ServiceHost(typeof(MyService));
foreach(ServiceEndpoint endpoint in host.Description.Endpoints)
{
endpoint.Behaviors.Add(behavior);
}
host.Open();
Можно инкапсулировать и автоматизации шагов в рис. 3 с помощью методов расширения, таких как методы SetServiceBusPassword Мой ServiceBusHelper статический класс, показанный здесь:
public static class ServiceBusHelper
{
public static void SetServiceBusPassword(this ServiceHost host, string password);
public static void SetServiceBusPassword(this ServiceHost host, string solution,string password);
}
С помощью этих расширений рис. 3 сжимается следующее:
ServiceHost host = new ServiceHost(typeof(MyService));
host.SetServiceBusPassword("MyPassword");
host.Open();
Реализация методов SetServiceBusPassword можно просмотреть без обработки ошибок в пример кода, прилагаемый к данной статье.
ServiceBusHelper определяет метод закрытый вспомогательный SetBehavior, который принимает коллекция конечных точек и присваивает все конечные точки в коллекции предоставленного объекта TransportClientEndpointBehavior. Закрытый вспомогательные методы SetServiceBusPassword принимать набор конечных точек, пароль решения и при необходимости имя решения. Если имя решения не указан, SetServiceBusPassword извлекает его из адрес первой конечной точки. SetServiceBusPassword создает TransportClientEndpointBehavior, настраивает его на использовать пароль затем вызывает SetBehavior. Открытые методы SetServiceBusPassword просто вызвать закрытый те коллекции конечных точек узла.
Клиент должен выполните аналогичные действия, за исключением имеется только одна конечная точка для настройки — один прокси-сервера используется, как показано на рис. 4.
Установка пароля решений на прокси-сервера на рисунке 4
TransportClientEndpointBehavior behavior =
new TransportClientEndpointBehavior();
behavior.CredentialType = TransportClientCredentialType.UserNamePassword;
behavior.CredentialType = TransportClientCredentialType.UserNamePassword;
behavior.Credentials.UserName.UserName = "MySolution";
behavior.Credentials.UserName.Password = "MyPassword";
MyContractClient proxy = new MyContractClient();
proxy.Endpoint.Behaviors.Add(behavior);
proxy.MyMethod();
proxy.Close();
Снова необходимо инкапсулировать повторяющегося кода с помощью методов расширения и предлагают подобные поддержки для работы с фабрики классов. С помощью этих расширений, рис. 4 сжимается в этот код:
MyContractClient proxy = new MyContractClient();
proxy.SetServiceBusPassword("MyPassword");
proxy.MyMethod();
proxy.Close();
На рис. 5 показана реализация двух SetServiceBusPassword клиентский < T >расширения. Примечание использование методов вспомогательных SetServiceBusPassword путем заключения одну конечную точку прокси-сервер имеет коллекция конечных точек.
На рисунке 5 реализация SetServiceBusPassword < T >
public static class ServiceBusHelper
{
public static void SetServiceBusPassword<T>(this ClientBase<T> proxy,
string password) where T : class
{
if(proxy.State == CommunicationState.Opened)
{
throw new InvalidOperationException("Proxy is already opened");
}
proxy.ChannelFactory.SetServiceBusPassword(password);
}
public static void SetServiceBusPassword<T>(this ChannelFactory<T> factory,
string password) where T : class
{
if(factory.State == CommunicationState.Opened)
{
throw new InvalidOperationException("Factory is already opened");
}
Collection<ServiceEndpoint> endpoints =
new Collection<ServiceEndpoint>();
endpoints.Add(factory.Endpoint);
SetServiceBusPassword(endpoints,password);
}
//More members
}
Поскольку TransportClientEndpointBehavior еще поведения конечной точки, можно также настроить его в файле конфигурации. Однако хранение пароля в файле config текст, является очень inadvisable.
Сертификат подлинности
С помощью сертификата для проверки подлинности от шины служб .NET является лучшим выбором неинтерактивных приложений и установите сертификат, и программными средствами и в файле конфигурации.
Основной препятствие с помощью сертификатов — это сертификат должен содержать закрытый ключ, который влечет за собой последовательность сложные настройки администратором решения. Однако после настройки решения для использования сертификата оставшейся части работы является простым.
Клиентом и размещения службы используйте идентичные конфигурации операции, как показано в рис. 6.
Сертификат на рис. 6 решений в конфигурации
<endpoint behaviorConfiguration = "RelayCert"
...
/>
...
<behaviors>
<endpointBehaviors>
<behavior name = "RelayCert">
<transportClientEndpointBehavior credentialType =
"X509Certificate">
<clientCredentials>
<clientCertificate
findValue = "MyRelayCert"
storeLocation = "LocalMachine"
storeName = "My"
x509FindType = "FindBySubjectName"
/>
</clientCredentials>
</transportClientEndpointBehavior>
</behavior>
</endpointBehaviors>
</behaviors>
Для программного обеспечения сертификат на стороне главного приложения, необходимо выполнить действия аналогичны этих показано ранее в рис. 3. Помимо настройки типа учетных данных TransportClientCredentialType.X509Certificate, необходимо использовать метод SetCertificate свойства ClientCertificate на учетные данные. Здесь снова, имеется возможность рационализировать его с помощью методов расширения узла, как показано ниже:
public static class ServiceBusHelper
{
public static void SetServiceBusCertificate(this ServiceHost host);
public static void SetServiceBusCertificate(this ServiceHost host, string subjectName);
public static void SetServiceBusCertificate(this ServiceHost host, object findValue,StoreLocation location,
StoreName storeName,X509FindType findType);
//More members
}
Например:
ServiceHost host = new ServiceHost(typeof(MyService));
host.SetServiceBusCertificate("MyRelayCert");
host.Open();
SetServiceBusCertificate по умолчанию хранилище для Мой компьютер и расположение для My, и он ищет сертификат по имени. SetServiceBusCertificate также извлекает имя решения из конечных точек узла.
Клиент также программным способом можно предоставить сертификат для использования на прокси-сервер, выполните действия аналогичны рис. 4 и можно автоматизировать, использование этих методов расширения, выполните те же значения по умолчанию, обсуждаются для узла:
public static class ServiceBusHelper
{
public static void SetServiceBusCertificate<T>(this ClientBase<T> proxy)
where T : class;
public static void SetServiceBusCertificate<T>(this ClientBase<T> proxy,
string subjectName) where T : class;
public static void SetServiceBusCertificate<T>(this ClientBase<T> proxy,
object findValue,StoreLocation location,StoreName
storeName,X509FindType findType) where T : class;
//Similar methods for a channel factory
}
Использование расширений на стороне клиента дает этот код:
MyContractClient proxy = new MyContractClient();
proxy.SetServiceBusCertificate("MyRelayCert");
proxy.MyMethod();
proxy.Close();
Без проверки подлинности
Хотя служба должна всегда проверку шины служб, можно исключить клиента и разрешить несанкционированный доступ к службе ретрансляции. В этом случае клиент должно присвоено TransportClientEndpointBehavior TransportClientCredentialType.Unauthenticated. Когда клиенты не проверенным служба ретрансляции, это теперь до ретранслируемой службы проверки подлинности клиентов. Недостатком является, служба теперь менее защищен чем когда служба ретрансляции проверку подлинности клиентов. Кроме того необходимо использовать защиту сообщений для передачи учетных данных клиента (как описано далее). Чтобы разрешить доступ без проверки подлинности клиентом, служба и клиент должен явно разрешить его путем настройки ретрансляции привязки не проходят проверку подлинности, с помощью перечисления RelayClientAuthenticationType, показанный здесь:
public enum RelayClientAuthenticationType
{
RelayAccessToken, //Default
None
}
Можно назначить, перечисления через свойства безопасности.
Перенос безопасности
Следующий ключевой аспект безопасности — безопасно перенос сообщения через передавать в службу. В дополнение к безопасность передачи сообщений другой важно разработки, решение, какие клиентские учетные данные (если таковые имеются) сообщение должно содержать. Безопасность передачи не зависит от как клиент или служба свою от шины служб .NET.
Шина служб .NET предлагает четыре варианта для обеспечения безопасности передачи представленного перечисления EndToEndSecurityMode:
public enum EndToEndSecurityMode
{
None,
Transport,
Message,
TransportWithMessageCredential //Mixed
}
Четыре варианты нет, передачи, сообщений и смешанном режиме. None означает просто — сообщение вообще не защищен. Транспорт использует HTTPS и SSL для защиты передачи сообщений. Безопасность сообщений шифрует тело сообщения, что могут отправляться небезопасной транспортами. Смешанные использует сообщение безопасности содержат учетные данные клиента но передает сообщение через безопасный транспорта. На рис. 7 показывает способ привязки relay поддерживает различные режимы безопасности передачи и их значения по умолчанию. Полужирный знак плюс (+) помечает по умолчанию.
| Перемещение безопасности и привязки на рис. 7 |
| Привязка | Не требуются. | Транспорт | Сообщение | Смешанный |
| TCP (ретрансляцию) | + | + | + | + |
| TCP (Direct гибридный) | + | - | + | - |
| WS | + | + | + | + |
| One-Way | + | + | + | - |
Настроить безопасность передачи в привязке. Хотя привязки ретрансляции использовать значения по умолчанию, все привязки ретрансляции предлагают крайней мере один конструктор, принимающий EndToEndSecurityMode как параметр построения. Также можно настроить безопасность передачи после создания, доступа к свойства безопасности и его свойство режим.
Защита канала связи
Когда доходит до передачи безопасности безопасность транспорта проще установить и настроить. Используя безопасность транспорта, все вызовы клиента при анонимных — клиент сообщения не содержат никаких учетных данных клиента. Является простым для использования безопасности транспорта, он не обеспечивает шифрование на всем безопасности. Защищает только передачи сообщения служба ретрансляции и из служба ретрансляции. Путешествия внутри службы ретрансляции не защищен.
Это означает, что в теории, служба ретрансляции может eavesdrop на связи между клиентом и службой и даже вмешиваться сообщения. Тем не менее я полагаю, что на практике это неудобно присваивается объем трафика шины служб .NET. Попросту говоря, этот вид subversion нельзя выполнить как сторону и требует выделенные ресурсы, планирования, персонала и технологии. Кроме того Майкрософт оказалось лет, он имеет наивысший целостность и отношении своих клиентовконфиденциальность и имеет множество областей, может злоупотребления если бы он был действительно вредоносные.
Защита сообщений
Безопасность сообщений шифрует тело сообщения с использованием сертификата предоставляемый службы. Поскольку само сообщение защищен вместо передачи, также защищен путешествия внутри передачу. Недостатком сообщение безопасности является требуется дополнительная настройка действия.
Несмотря на я думаю, что в практике транспорта безопасности достаточно, не важно обеспечить клиентов и пользователей присутствия для комплексного конфиденциальность и целостность и защититься от даже теоретической компромиссы. Поэтому рекомендуется всегда полагаться на безопасности сообщений для всех ретранслируемой связи, также предоставляют дополнительные преимущества, такие как прямое подключение и доступность контекст вызова безопасности для службы.
В отличие от в безопасности транспорта в сообщение безопасности сообщения могут содержать учетные данные клиента. Основные учетные данные клиента службой используется для локальной авторизации вызов некоторые политики безопасности на основе ролей. Когда сообщение содержит учетные данные, служба должен пройти также подлинности их (даже если все ему для авторизации клиента). Заметьте, что такой проверки подлинности находится на вершине ретрансляции службы проверки подлинности уже выполнил. Если служба ретрансляции уже проверку подлинности клиента, проверка подлинности вызова снова службой не добавляет большая способом часть безопасности, но burdens службы с управление учетные данные клиента. Если служба ретрансляции не проверяет подлинность клиента, службы будут быть проверяется для нежелательного трафика без проверки подлинности клиентов, может иметь серьезные последствия операции ИТ.
По этим причинам найти оптимальным является для проверки подлинности клиента и избежать службу снова сделать службы ретрансляции. Также следует разрабатывать службу, что он не имеет потребность учетные данные клиента. Такой макет выравнивается шаблон разработки цепочку доверия, хорошо работает в многоуровневой архитектуры. С другой стороны, существуют случаи, когда служба требуются учетные данные клиента для локального использования отличные от авторизации, например персонализации, аудит или собственных интеграции с устаревшими системами.
Привязка ретрансляции TCP и безопасности передачи
Умолчанию привязки ретрансляции TCP для передачи безопасности и не действия специальной настройки являются обязательными. Он просто использует SSL через порт 828. При использовании безопасность транспорта, однако можно использовать только режим подключения TCP ретрансляции привязки, TcpRelayConnectionMode.relayed.
Поскольку вызов является анонимным, со стороны службы Windows Communication Foundation (WCF) присоединяет универсального участника с удостоверением пустой поток, выполняющий вызов и ServiceSecurityContext имеет значение null.
Для защиты передачи сообщения, необходимо настроить размещения службы с помощью сертификата. Клиент будет по умолчанию согласовывать сертификат (получить открытый ключ), поэтому нет необходимости явно списке сертификата в файле конфигурации клиента. Тем не менее клиент по-прежнему необходимо проверить согласованный сертификат. С обычной WCF и безопасность сообщений, рекомендуется проверить сертификат, с помощью одноранговых доверия, что означает заранее Установка сертификата в папку надежных лиц клиента. Помимо значение true, передача шифрование на всем безопасности через передачу с помощью безопасности сообщения также позволяет использовать прямой и гибридные режима подключения.
Как обсуждалось ранее, сообщение может или не может содержать учетные данные клиента. Если избежать посылает учетные данные в сообщение WCF будет присоединен поток, выполняющий вызов участник с пустым удостоверение, которое не имеет смысла гораздо Windows. При использовании безопасность сообщений без учетных данных, следует также установить узел PrincipalPermissionMode нет, чтобы получить же участника как с безопасностью транспорта. Чтобы настроить привязки для безопасности сообщений с анонимным вызовов, используйте MessageCredentialType.None и присвоить значение свойству ClientCredentialType MessageSecurityOverRelayConnection, доступные в свойстве Message NetTcpRelaySecurity. На рис. 8 показан код, это демонстрируется.
Настройка привязки для безопасности сообщений с анонимные вызовы на рисунке 8
public sealed class NetTcpRelaySecurity
{
public EndToEndSecurityMode Mode
{get;set;}
public MessageSecurityOverRelayConnection Message
{get;}
//More members
}
public sealed class MessageSecurityOverRelayConnection
{
public MessageCredentialType ClientCredentialType
{get;set;}
//More members
}
На рисунке 9 показан файл конфигурации требуется стороне главного приложения.
На рисунке 9 Настройка размещения сообщений безопасности
<service name = "..." behaviorConfiguration = "MessageSecurity">
<endpoint
...
binding = "netTcpRelayBinding"
bindingConfiguration = "MessageSecurity"
/>
</service>
...
<serviceBehaviors>
<behavior name = "MessageSecurity">
<serviceCredentials>
<serviceCertificate
findValue = "MyServiceCert"
storeLocation = "LocalMachine"
storeName = "My"
x509FindType = "FindBySubjectName"
/>
</serviceCredentials>
<serviceAuthorization principalPermissionMode ="None"/>
</behavior>
</serviceBehaviors>
<bindings>
<netTcpRelayBinding>
<binding name = "MessageSecurity">
<security mode = "Message">
<message clientCredentialType = "None"/>
</security>
</binding>
</netTcpRelayBinding>
</bindings>
На стороне клиента необходимо включить название сертификата службы в идентификации адрес конечной точки, поскольку это имя не соответствует домене службы ретрансляции. На рис. 10 показан файл конфигурации требуется.
Рисунок 10 настройке клиента безопасности сообщения
<client>
<endpoint behaviorConfiguration = "ServiceCertificate"
binding = "netTcpRelayBinding"
bindingConfiguration = "MessageSecurity"
<identity>
<dns value = "MyServiceCert"/>
</identity>
...
</endpoint>
</client>
<bindings>
<netTcpRelayBinding>
<binding name = "MessageSecurity">
<security mode = "Message">
<message clientCredentialType = "None"/>
</security>
</binding>
</netTcpRelayBinding>
</bindings>
<behaviors>
<endpointBehaviors>
<behavior name = "ServiceCertificate">
<clientCredentials>
<serviceCertificate>
<authentication certificateValidationMode= "PeerTrust"/>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
Если требуется включить в сообщение учетные данные клиента службы должен также проверка подлинности эти учетные данные с того же параметра как обычные вызовы TCP. В этом случае удостоверение участника и основной службы будут иметь удостоверение соответствия эти учетные данные. Учетных данных может быть имя пользователя и пароль, сертификат или выданного маркера. Необходимо указать узел и клиенте в привязке которой предполагается, что типы учетных данных. Например учетные данные имени пользователя используется:
<bindings>
<netTcpRelayBinding>
<binding name = "MessageSecurity">
<security mode = "Message">
<message clientCredentialType = "UserName"/>
</security>
</binding>
</netTcpRelayBinding>
</bindings>
На стороне узла, если учетные данные имени пользователя и пароль, необходимо также настроить, с помощью поведения, способы проверки подлинности и авторизации учетных данных. По умолчанию будет учетные данные Windows, но чаще выбор будет использоваться некоторые хранилище учетных данных, например поставщиков ASP.NET:
<service name = "..." behaviorConfiguration = "CustomCreds">
...
</service>
...
<serviceBehaviors>
<behavior name = "CustomCreds">
<serviceCredentials>
<userNameAuthentication
userNamePasswordValidationMode = "MembershipProvider"
/>
</serviceCredentials>
<serviceAuthorization principalPermissionMode = "UseAspNetRoles"/>
</behavior>
</serviceBehaviors>
Клиент имеет заполнения прокси-сервер с учетными данными. При использовании имени пользователя и пароля, клиентский код будет вставить следующим образом:
MyContractClient proxy = new MyContractClient();
proxy.ClientCredentials.UserName.UserName = "MyUserName";
proxy.ClientCredentials.UserName.Password = "MyPassword";
proxy.MyMethod();
proxy.Close();
Клиент не могло различить, если он предоставляет учетные данные проходят проверку подлинности со стороны службы Windows или пользовательские учетные данные.
Смешанная передача безопасности является единственным способом избежать анонимные вызовы через безопасности транспорта. Поскольку безопасность транспорта не удается передать учетные данные, необходимо передать учетные данные, поэтому используя безопасность сообщений, смешанные термин. Только когда с помощью безопасности Смешанная передача через TCP ретрансляции, привязки, ограничены использования обслуживающих подключений.
На рис. 11 демонстрируется настройка службы или клиента для смешанного режима безопасности.
На рисунке 11, настройка для смешанного безопасности
<endpoint
binding = "netTcpRelayBinding"
bindingConfiguration = "MixedSecurity"
...
/>
...
<bindings>
<netTcpRelayBinding>
<binding name = "MixedSecurity">
<security mode = "TransportWithMessageCredential"/>
</binding>
</netTcpRelayBinding>
</bindings>
После получения службой сообщения узла должен проверку подлинности вызовов как с помощью обычных TCP. После проверки подлинности вызова службы будет иметь основной объект, соответствующий указанные учетные данные и контекст вызова безопасности.
Привязка WS ретрансляции и безопасности передачи
Объединяя привязки WS с безопасность транспорта как прост, как изменение схемы адрес с HTTP на HTTPS и настройка привязки для использования безопасности транспорта, как показано на рис. 12.
Привязка WS ретрансляции на рис. 12 с безопасностью транспорта
<endpoint
address = "https://MySolution.servicebus.windows.net/..."
binding = "wsHttpRelayBinding"
bindingConfiguration = "TransportSecurity"
...
/>
<bindings>
<wsHttpRelayBinding>
<binding name = "TransportSecurity">
<security mode = "Transport"/>
</binding>
</wsHttpRelayBinding>
</bindings>
Обратите внимание, WS ретрансляции привязки по умолчанию, используя безопасности сообщений для обеспечения безопасности передачи. Поскольку безопасности сообщений требует дополнительной настройки действия, WS ретрансляции привязки не работает как - находится вне поле и все вызовы не удастся. Однако Настройка ретрансляции WS привязки для использования сообщения (или смешанный) безопасности идентична Настройка привязки ретрансляции TCP.
One-Way привязка ретрансляции и безопасности передачи
Одностороннее ретрансляции привязки (и его подклассов) является только привязку, которая по умолчанию отсутствие передачи безопасности вообще. Кроме того он не поддерживает смешанные передачи безопасности. Настройка на использование безопасности транспорта совпадает с привязками ретрансляции TCP- и WS. Настройка будет использовать защиту сообщений является похоже, но с одним важным отличием — привязки односторонние ретрансляции не могут согласовать сертификат службы, поскольку не может даже быть службы, а не происходит непосредственного взаимодействия со службой. При использовании безопасность сообщений на клиентском компьютере, необходимо явно указать сертификат службы, как показано на рис. 13.
Рис 13 одностороннее связывание ретрансляции с безопасностью сообщений
<client>
<endpoint behaviorConfiguration = "ServiceCertificate"
...
</endpoint>
</client>
<behaviors>
<endpointBehaviors>
<behavior name = "ServiceCertificate">
<clientCredentials>
<serviceCertificate>
<scopedCertificates>
<add targetUri = "sb://MySolution.servicebus..."
findValue = "MyServiceCert"
storeLocation = "LocalMachine"
storeName = "My"
x509FindType = "FindBySubjectName"
/>
</scopedCertificates>
</serviceCertificate>
</clientCredentials>
</behavior>
</endpointBehaviors>
</behaviors>
Другой важной различие между привязки односторонние ретрансляции и других привязок ретрансляции том, что если вызов является анонимным с безопасностью транспорта или сообщение, вызов которого первичный идентификатор — контекст вызова безопасности
service bus certificate CN=servicebus.windows.net.
Оптимизация передачи безопасности
Во время передачи безопасности предлагает выявить сложных параметров и сведений, можно и должен оптимизировать и автоматизировать большая часть этих решений конфигурации безопасности. Для инкапсуляции на стороне главного приложения Мой класс ServiceBusHost определен как вставки следующее:
public class ServiceBusHost : ServiceHost
{
public ServiceBusHost(object singletonInstance, params Uri[] baseAddresses);
public ServiceBusHost(Type serviceType,params Uri[] baseAddresses);
public void ConfigureAnonymousMessageSecurity(string serviceCert);
public void ConfigureAnonymousMessageSecurity(string serviceCert,
StoreLocation location,StoreName storeName);
public void ConfigureAnonymousMessageSecurity(StoreLocation location,
StoreName storeName,X509FindType findType,object findValue);
//More members
}
При использовании ServiceBusHost другой параметр в файле конфигурации или в коде не требуется. На мой рекомендация ConfigureAnonymousMessageSecurity метод служит для включить анонимные вызовы через безопасности сообщений. Чтобы предоставить его достаточно имя сертификата для использования:
ServiceBusHost host = new ServiceBusHost(typeof(MyService));
host.ConfigureAnonymousMessageSecurity("MyServiceCert");
host.Open();
ConfigureAnonymousMessageSecurity по умолчанию расположение сертификата для локального компьютера и хранилище сертификатов для My, и будет выглядеть сертификата по общему имени. При вызове ConfigureAnonymousMessageSecurity ServiceBusHost по умолчанию с помощью анонимного сообщение безопасности с именем решения для имени сертификата:
ServiceBusHost host = new ServiceBusHost(typeof(MyService));
host.Open();
Можно также использовать перегруженные версии, позволяющие явно задавать некоторые или все сведения о сертификате.
Позволяет использовать ConfigureBinding ServiceBusHost ServiceBusHelper метода. ConfigureBinding по умолчанию анонимные вызовы. Если вызовы должны иметь учетные данные, ConfigureBinding всегда использует учетные данные пользователя. С помощью привязки ретрансляции TCP ConfigureBinding использует режим подключения гибридный. ConfigureBinding позволяет также всегда надежный сообщения.
ServiceBusHost также поддерживает безопасность сообщений с учетными данными посредством методов ConfigureMessageSecurity:
public class ServiceBusHost : ServiceHost
{
public void ConfigureMessageSecurity();
public void ConfigureMessageSecurity(string serviceCert);
public void ConfigureMessageSecurity(string serviceCert,
string applicationName);
public void ConfigureMessageSecurity(string serviceCert,
bool useProviders,
string applicationName);
//More members
}
ConfigureMessageSecurity по умолчанию с помощью поставщиков членства ASP.NET, но это рекомендовано использовать также учетные записи Windows. Реализация ConfigureMessageSecurity является аналогичный ConfigureAnonymousMessageSecurity.
Можно предоставить клиентам простой способ настройки безопасности сообщений с моей ServiceBusClientBase < T > определен как
public abstract class ServiceBusClientBase<T> : ClientBase<T> where T : class
{
public ServiceBusClientBase();
public ServiceBusClientBase(string endpointName);
public ServiceBusClientBase(Binding binding,
EndpointAddress remoteAddress);
public ServiceBusClientBase(string username,string password);
public ServiceBusClientBase(string endpointName,
string username,string password);
public ServiceBusClientBase(Binding binding,EndpointAddress address,
string username,string password);
protected virtual void ConfigureForServiceBus();
protected virtual void ConfigureForServiceBus(string username, string password);
}
ServiceBusClientBase < T >предоставляет два набора конструкторы. Конструкторы, просто параметры конечной точки все по умолчанию с безопасностью сообщений анонимные вызовы. Можно также использовать конструкторов, принимающего учетные данные имени пользователя и пароля. Если конечная точка адрес удостоверение предоставляется, ServiceBusClientBase < T >по умолчанию его имя решения. Использовать ServiceBusClientBase < T >как предоставляемый WCF ClientBase < T >:
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyContractClient : ServiceBusClientBase<IMyContract>,IMyContract
{
public MyContractClient()
{}
public void MyMethod()
{
Channel.MyMethod();
}
}
Пример кода для загрузки включает полную реализацию ServiceBusClientBase < T >. ServiceBusClientBase < T >для проверки сертификата службы используется доверием одноранговой группы. Основная часть работы выполняется путем передачи ServiceBusHelper.ConfigureBinding привязки конечной точки.
Один пункт оставшиеся ободранными является привязка односторонние ретрансляции с его отсутствие согласования сертификата. Чтобы облегчить, я написал OneWayClientBase < T >:
public abstract class OneWayClientBase<T> : ServiceBusClientBase<T> where T : class
{
//Same constructors as ServiceBusClientBase<T>
public void SetServiceCertificate(string serviceCert);
public void SetServiceCertificate(string serviceCert,
StoreLocation location,
StoreName storeName);
public void SetServiceCertificate(object findValue,
StoreLocation location,StoreName storeName,X509FindType findType);
}
OneWayClientBase < T >является производным от ServiceBusClientBase < T >и добавляет методы SetServiceCertificate. Если не вызвать SetServiceCertificate, OneWayClientBase < T >просто ищет сертификат службы из конфигурации. SetServiceCertificate предлагает простой программный способ, полностью избежать файла конфигурации. Он даже задает тег удостоверение адрес конечной точки. SetServiceCertificate использует одинаковые значения по умолчанию как ServiceBusHost, включая использование имя решения имя сертификата, если сертификат не предоставляется. Вот, как использовать OneWayClientBase < T >:
class MyContractClient : OneWayClientBase<IMyContract>,IMyContract
{
public MyContractClient()
{}
public void MyMethod()
{
Channel.MyMethod();
}
}
MyContractClient proxy = new MyContractClient();
proxy.SetServiceCertificate("MyServiceCert");
proxy.MyMethod();
proxy.Close();
Как вы видите, используя OneWayClientBase < T >достаточно прост.
Вопросы и комментарии направляйте по адресу mmnet30@microsoft.com.
Джувел Лоуи архитектуры программного обеспечения IDesign, проводящий обучение по WCF и дающий консультации по архитектуре. Программирование служб WCF является его последней книги второй выпуск (O'Reilly, 2008). Является региональным директором Майкрософт в Силиконовой долине. Связаться с Джувелом можно через веб-узел www.idesign.net.