Поделиться через

Поведения безопасности в WCF

  • Статья

В Windows Communication Foundation (WCF) поведения изменяют порядок работы во время выполнения на уровне службы или на уровне конечной точки. (Дополнительные сведения о поведениях в целом см. в разделе Указание поведения службы во время выполнения.) Поведения безопасности позволяют управлять учетными данными, проверкой подлинности, авторизацией и журналами аудита. Поведения можно использовать путем программирования или через конфигурацию. В этом разделе основное внимание уделяется настройке следующих поведений, связанных с функциями безопасности:

Задание учетных данных с помощью поведений

Чтобы задать значения учетных данных для службы или клиента, используйте элементы serviceCredentials element и clientCredentials element. Необходимость задания учетных данных определяется конфигурацией используемой привязки. Например, если задан режим безопасности None, ни клиенты, ни службы не проверяют подлинность друг друга и не требуют учетных данных какого-либо типа.

С другой стороны, привязка службы может требовать тип учетных данных клиента. В этом случае может потребоваться задать значение учетных данных с помощью поведения. (Дополнительные сведения о возможных типах учетных данных см. в разделе Выбор типа учетных данных.) В некоторых случаях (например, если для проверки подлинности используются учетные данные Windows), среда автоматически устанавливает фактическое значение учетных данных, и не нужно явно задавать это значение (кроме случая, когда требуется указать другой набор учетных данных).

Все учетные данные службы находятся в дочерних элементах раздела serviceBehaviors section. В следующем примере показан сертификат, используемый в качестве учетных данных службы.

<configuration>
 <system.serviceModel>
  <behaviors>
   <serviceBehaviors>
    <behavior name="ServiceBehavior1">
     <serviceCredentials>
      <serviceCertificate findValue="000000000000000000000000000" 
                          storeLocation="CurrentUser"
      storeName="Root" x509FindType="FindByThumbprint" />
     </serviceCredentials>
    </behavior>
   </serviceBehaviors>
  </behaviors>
 </system.serviceModel>
</configuration>

Учетные данные службы

Элемент <serviceCredentials> Element содержит четыре дочерних элемента. Эти элементы и их применение рассматриваются в следующих подразделах.

Элемент <serviceCertificate>

Этот элемент используется для задания сертификата X.509, который используется для проверки подлинности службы при подключении к клиентам в режиме безопасности сообщений. Если используется сертификат, который периодически обновляется, то его отпечаток изменяется. В этом случае следует использовать имя субъекта в виде X509FindType, поскольку сертификат может быть выдан повторно с тем же именем субъекта.

Дополнительные сведения об использовании элемента см. в разделе Как задать значения учетных данных клиента.

<certificate> элемента <clientCertificate>

Элемент <certificate> используется в случаях, когда служба должна заранее получить сертификат клиента для безопасного обмена данными с клиентом. Это характерно для дуплексного обмена данными. В более распространенном варианте "запрос/ответ" клиент включает сертификат в запрос, который используется службой для обеспечения безопасности отклика, направляемого назад клиенту. Однако при дуплексном обмене данными запросы и ответы не используются. Служба не может логически вывести сертификат клиента из передаваемых данных, поэтому служба должна заранее получить сертификат клиента, чтобы обеспечить безопасность сообщений для клиента. Необходимо получить сертификат клиента с использованием внештатного канала и указать сертификат с помощью этого элемента. Дополнительные сведения дуплексных службах см. в разделе Как создавать дуплексный контракт.

<authentication> элемента <clientCertificate>

Элемент <authentication> позволяет настраивать способ проверки подлинности клиентов. Для атрибута CertificateValidationMode можно задать значение None, ChainTrust, PeerOrChainTrust, PeerTrust или Custom. По умолчанию установлен уровень ChainTrust, который определяет, что каждый сертификат должен находиться в иерархии сертификатов, заканчивающейся корневым центром на вершине цепи. Это наиболее безопасный режим. Также можно установить значение PeerOrChainTrust, в этом случае будут приниматься как самостоятельно выдаваемые сертификаты (доверие одноранговой группы), так и сертификаты, которые находятся в цепи доверия. Данное значение используется при разработке и отладке клиентов и служб, так как самостоятельно выданные сертификаты не нужно приобретать у доверенного центра сертификации. При развертывании клиента вместо этого значения следует использовать значение ChainTrust. Также можно установить значение Custom. При установке значения Custom необходимо также задать атрибут CustomCertificateValidatorType для сборки и тип, который используется при проверке сертификата. Для создания собственного пользовательского модуля проверки необходимо наследование от абстрактного класса X509CertificateValidator.

Элемент <issuedTokenAuthentication>

В сценарии с выданным маркером имеется три этапа. На первом этапе клиент, который пытается получить доступ к службе, направляется к службе маркеров безопасности (STS). Затем служба маркеров безопасности проводит проверку подлинности клиента и выдает клиенту маркер, обычно на языке Security Assertions Markup Language (SAML). После этого клиент возвращается к службе с этим маркером. Служба проверяет наличие в маркере данных, позволяющих проверить подлинность маркера и, соответственно, самого клиента. Для проверки подлинности маркера сертификат, используемый службой маркеров безопасности, должен быть известен службе. Элемент <issuedTokenAuthentication> является хранилищем подобных сертификатов службы маркеров безопасности. Используйте элемент <knownCertificates>, чтобы добавить сертификаты. Вставьте элемент <add> of <knownCertificates> для каждого сертификата, как показано в следующем примере.

<issuedTokenAuthentication>
   <knownCertificates>
      <add findValue="www.contoso.com" 
           storeLocation="LocalMachine" storeName="My" 
           X509FindType="FindBySubjectName" />
    </knownCertificates>
</issuedTokenAuthentication>

По умолчанию сертификаты должны быть получены от службы маркеров безопасности. Эти "известные" сертификаты гарантируют, что доступ к службе могут получить только допустимые клиенты.

Коллекцию <allowedAudienceUris> следует использовать в федеративном приложении, которое использует службу маркеров безопасности (STS), выдающую маркеры безопасности SamlSecurityToken. При выпуске маркера безопасности служба STS также может указать универсальный код ресурса (URI) веб-служб, для которых предназначен маркер безопасности, добавив выражение SamlAudienceRestrictionCondition к маркеру безопасности. Это позволяет коду SamlSecurityTokenAuthenticator для веб-службы получателя проверить, что выданный маркер безопасности предназначен для данной службы, указав на необходимость выполнения соответствующей проверки. Для этого выполните следующие действия.

  • Присвойте атрибуту audienceUriMode элемента <issuedTokenAuthentication> значение Always или BearerKeyOnly.

  • Задайте набор допустимых URI, добавив их в эту коллекцию. Для этого вставьте элемент <add> element <AllowedAudienceUris> Element для каждого универсального кода ресурса (URI).

Дополнительные сведения см. в разделе SamlSecurityTokenAuthenticator.

Дополнительные сведения об использовании этого элемента конфигурации см. в разделе Как настраивать учетные данные службы федерации.

Разрешение анонимных пользователей CardSpace

Если для атрибута AllowUntrustedRsaIssuers элемента <IssuedTokenAuthentication> явно задано значение true, любой клиент может представить самостоятельно выданный маркер, подписанный произвольной парой ключей RSA. Этот издатель является ненадежным, так как с ключом не связаны никакие данные издателя. Пользователь CardSpace может создать самостоятельно изданную карту, содержащую самостоятельно предоставленные утверждения идентификации. Эту возможность следует использовать с осторожностью. Используя эту функцию, считайте открытый ключ RSA просто более безопасным паролем, который должен храниться в базе данных вместе с именем пользователя. Прежде чем разрешить клиенту доступ к службе, проверьте представленный клиентом открытый ключ RSA, сравнив его с хранящимся открытым ключом для указанного имени пользователя. Это подразумевает, что организован процесс регистрации, в котором пользователи могут регистрировать свои имена пользователя и связывать их с самостоятельно изданными открытыми ключами RSA.

Учетные данные клиента

Учетные данные клиента используются для проверки подлинности клиента при подключении к службам в случаях, когда требуется взаимная проверка подлинности. Данный раздел можно использовать для задания сертификатов служб для сценариев, где клиент должен обеспечить защиту сообщений, передаваемых службе, с помощью сертификатов службы.

Можно также настроить клиент как часть сценария федерации для использования маркеров, изданных службой маркеров безопасности или локальным издателем маркеров. Дополнительные сведения сценариях федерации см. в разделе Федерация и выданные маркеры. Все учетные данные клиентов находятся в разделе endpointBehaviors section, как показано в следующем коде.

<behaviors>
 <endpointBehaviors>
  <behavior name="EndpointBehavior1">
   <clientCredentials>
    <clientCertificate findValue="cn=www.contoso.com"   
        storeLocation="LocalMachine"
        storeName="AuthRoot" x509FindType="FindBySubjectName" />
    <serviceCertificate>
     <defaultCertificate findValue="www.cohowinery.com" 
                    storeLocation="LocalMachine"
                    storeName="Root" x509FindType="FindByIssuerName" />
    <authentication revocationMode="Online"
                    trustedStoreLocation="LocalMachine" />
    </serviceCertificate>
   </clientCredentials>
  </behavior>
 </endpointBehaviors>

Элемент <clientCertifictate>

Задает сертификат, используемый для проверки подлинности клиента с помощью этого элемента. Дополнительные сведения см. в разделе Как задать значения учетных данных клиента.

<httpDigest>

Эта функция должна быть включена с помощью Active Directory в Windows и службах IIS. Дополнительные сведения см. в разделе Дайджест-проверка подлинности в IIS 6.0.

Элемент <issuedToken>

<issuedToken> of <clientCredentials> element содержит элементы, используемые для настройки локального издателя маркеров, или поведений, используемых со службой маркеров безопасности. Инструкции по настройке клиента на работу с локальным издателем см. в разделе Как настраивать локальный издатель.

<localIssuerAddress>

Задает адрес службы маркеров безопасности по умолчанию. Этот адрес используется, если WSFederationHttpBinding не предоставляет URL-адрес для службы маркеров безопасности или если адрес издателя федеративной привязки имеет значение https://schemas.microsoft.com/2005/12/ServiceModel/Addressing/Anonymous либо null. В этих случаях необходимо настроить объект ClientCredentials с использованием адреса локального издателя и привязки, с помощью которой будет осуществляться взаимодействие с этим издателем.

<issuerChannelBehaviors>

<issuerChannelBehaviors> Element WCF служит для добавления поведений клиента, которые будут использоваться при взаимодействии со службой маркеров безопасности. Поведения клиента определяются в разделе endpointBehaviors. Чтобы использовать определенное поведение, добавьте элемент <add> в элемент <issuerChannelBehaviors> с двумя атрибутами. Задайте в атрибуте issuerAddress URL-адрес службы маркеров безопасности, а в атрибуте behaviorConfiguration — имя определенного поведения конечной точки, как показано в следующем примере.

<clientCredentials>
   <issuedToken>
      <issuerChannelBehaviors>
         <add issuerAddress="https://www.contoso.com"
               behaviorConfiguration="clientBehavior1" />

Элемент <serviceCertificate>

Этот элемент служит для управления проверкой подлинности сертификатов службы.

В элементе <defaultCertificate> может храниться один сертификат, используемый, если служба не указала никакого сертификата.

Используйте <scopedCertificates> Element<add> of <scopedCertificates> Element и для задания сертификатов службы, связанных с определенными службами. Элемент <add> содержит атрибут targetUri, который служит для связывания сертификата со службой.

Элемент <authentication> указывает уровень доверия, который используется при проверке подлинности сертификатов. По умолчанию для уровня устанавливается значение "ChainTrust", указывающее, что каждый сертификат должен находиться в иерархии сертификатов, которая на самом верху цепи завершается доверенным центром сертификации. Это наиболее безопасный режим. Также можно установить значение PeerOrChainTrust. В этом случае будут приниматься как самостоятельно выдаваемые сертификаты (доверие одноранговой группы), так и сертификаты, которые находятся в цепочке доверия. Данное значение используется при разработке и отладке клиентов и служб, так как самостоятельно выданные сертификаты не нужно приобретать у доверенного центра сертификации. При развертывании клиента вместо этого значения следует использовать значение "ChainTrust". Также можно задать значение "Custom" или "None". Чтобы использовать значение "Custom", необходимо также установить для атрибута CustomCertificateValidatorType значение сборки и типа, которые используются при проверке сертификата. Для создания собственного пользовательского модуля проверки необходимо наследование от абстрактного класса X509CertificateValidator. Дополнительные сведения см. в разделе Как создать службу, использующую пользовательский проверяющий элемент управления для сертификатов.

Элемент <authentication>RevocationMode содержит атрибут , который указывает способ проверки отзыва сертификатов. По умолчанию используется значение online, которое указывает, что проверка отзыва сертификата выполняется автоматически. Дополнительные сведения см. в разделе Работа с сертификатами.

ServiceAuthorization

Элемент <serviceAuthorization> содержит элементы, влияющие на авторизацию, поставщики пользовательских ролей и олицетворение.

Класс PrincipalPermissionAttribute применяется к методу службы. Этот атрибут указывает группы пользователей, которые следует использовать при авторизации использования защищенного метода. Значение по умолчанию — "UseWindowsGroups". Оно указывает, что при попытке доступа к ресурсу поиск идентификации выполняется в таких группах Windows, как "Администраторы" или "Пользователи". Также можно задать атрибут UseAspNetRoles для использования поставщика пользовательской роли, который настроен в элементе <system.web>, как показано в следующем коде.

<system.web>
  <membership defaultProvider="SqlProvider" 
   userIsOnlineTimeWindow="15">
     <providers>
       <clear />
       <add 
          name="SqlProvider" 
          type="System.Web.Security.SqlMembershipProvider" 
          connectionStringName="SqlConn"
          applicationName="MembershipProvider"
          enablePasswordRetrieval="false"
          enablePasswordReset="false"
          requiresQuestionAndAnswer="false"
          requiresUniqueEmail="true"
          passwordFormat="Hashed" />
     </providers>
   </membership>
  <!-- Other configuration code not shown.-->
</system.web>

В следующем примере показано использование элемента roleProviderName с атрибутом principalPermissionMode.

<behaviors>
 <behavior name="ServiceBehaviour">        
  <serviceAuthorization principalPermissionMode ="UseAspNetRoles" 
                        roleProviderName ="SqlProvider" />
</behavior> 
   <!-- Other configuration code not shown. -->
</behaviors>

Настройка аудита безопасности

serviceSecurityAudit element служит для задания журнала, в который производится запись, и типов регистрируемых событий. Дополнительные сведения см. в разделе Аудит событий безопасности.

<system.serviceModel>
<serviceBehaviors>
  <behavior name="NewBehavior">
    <serviceSecurityAudit auditLogLocation="Application" 
             suppressAuditFailure="true"
             serviceAuthorizationAuditLevel="Success" 
             messageAuthenticationAuditLevel="Success" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Безопасный обмен метаданными

Экспорт метаданных в клиенты удобен для разработчиков служб и клиентов, так как позволяет загружать конфигурацию и код клиента. Для снижения подверженности службы действиям недобросовестных пользователей перенос можно защитить с помощью механизма SSL по протоколу HTTP (HTTPS). Для этого необходимо вначале выполнить привязку подходящего сертификата X.509 к конкретному порту компьютера, на котором размещена служба. (Дополнительные сведения см. в разделе Работа с сертификатами.) Затем добавьте в конфигурацию службы элемент <serviceMetadata> ElementHttpsGetEnabled и задайте для атрибута true значение . После этого следует присвоить атрибуту HttpsGetUrl URL-адрес конечной точки метаданных службы, как показано в следующем примере.

<behaviors>
 <serviceBehaviors>
  <behavior name="NewBehavior">
    <serviceMetadata httpsGetEnabled="true" 
     httpsGetUrl="https://myComputerName/myEndpoint" />
  </behavior>
 </serviceBehaviors>
</behaviors>

См. также

Основные понятия

Аудит событий безопасности

Другие ресурсы

Модель безопасности для Windows Server App Fabric