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

  • Статья

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

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

Настройка учетных данных с помощью поведения

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

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

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

<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 <содержит четыре дочерних> элемента. Эти элементы и их применение рассматриваются в следующих подразделах.

<Элемент serviceCertificate>

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

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

<<сертификат> элемента clientCertificate>

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

<проверка подлинности> <элемента clientCertificate>

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

<Элемент issuedTokenAuthentication>

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

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

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

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

  • audienceUriMode Задайте для атрибута выданной <функцииTokenAuthentication Always> или .BearerKeyOnly

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

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

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

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

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

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

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

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

<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>
</behaviors>

<Элемент clientCertificate>

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

<httpDigest>

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

<Элемент issuedToken>

ВыданныйToken ><содержит элементы, используемые для настройки локального издателя токенов или поведения, используемых с службой маркеров безопасности. Инструкции по настройке клиента для использования локального издателя см. в статье "Практическое руководство. Настройка локального издателя".

<localIssuerAddress>

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

<issuerChannelBehaviors>

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

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

<Элемент serviceCertificate>

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

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

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

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

Элемент <проверки подлинности> содержит атрибут, указывающий 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>, чтобы указать журнал, записанный в журнал, и какие типы событий следует регистрировать. Дополнительные сведения см. в разделе "Аудит".

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

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

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

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

См. также