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


Архитектура безопасности

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

Область компонента безопасности WCF

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

  • безопасность передачи — отвечает за обеспечение конфиденциальности сообщений, целостности данных и проверки подлинности взаимодействующих сторон;

  • авторизация — отвечает за формирование платформы для принятия решения об авторизации;

  • аудит — отвечает за регистрацию событий, связанных с обеспечением безопасности, в журнале аудита.

Режимы безопасности и область этого документа

Безопасность передачи может реализовываться с помощью одного из следующих режимов безопасности:

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

  • режим безопасности сообщений. Безопасность передачи обеспечивается только на уровне сообщений SOAP, что означает, что средства безопасности применяются непосредственно к сообщению SOAP на уровне XML;

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

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

Аналогично ко всем трем режимам безопасности относятся описания компонентов авторизации и аудита. Таким образом, вся приведенная в этом документе информация, относящаяся к этим компонентам, относится ко всем поддерживаемым режимам безопасности.

Принципы работы режима безопасности сообщений

Модель WS-Security

В основе режима безопасности сообщений лежит спецификация WS-Security. В спецификации WS-Security определяется платформа, которая позволяет применять к сообщениям SOAP средства безопасности. В ней задается модель безопасности сообщений, использующая маркеры безопасности, цифровые подписи и шифрование для защиты и проверки подлинности сообщений SOAP. Текст спецификации см. на странице WS-Security.

Терминология

Маркер безопасности служит для создания утверждений и позволяет создать привязку между секретными данным или ключами проверки подлинности и удостоверениями безопасности.

Утверждение — это заявление одной сущности о другой сущности (например, об имени, группе удостоверений, ключе, группе или привилегии). Сущность, которая создает утверждение, называется издателем утверждения; сущность, к которой относится утверждение, называется субъектом утверждения.

Издатель утверждения может подтверждать (выступать в качестве поручителя) утверждения в маркере безопасности с помощью своего ключа, с помощью которого подписывается или шифруется маркер безопасности. Это позволяет проверять подлинность утверждений в маркере безопасности.

Подписи сообщений служат для проверки источников и целостности сообщений. Кроме того, подписи сообщений используются создателями сообщений, чтобы показать, что им известен ключ (обычно сторонний), с помощью которого подтверждаются утверждения в маркере безопасности, и тем самым связать свое удостоверение (и все остальные утверждения в маркере безопасности) с создаваемым сообщением.

Маркеры безопасности

В спецификации WS-Security определено несколько типов маркеров безопасности и представлена расширяемая модель, позволяющая независимым образом определять дополнительные типы маркеров безопасности. Каждое определение типа маркера содержит XML-сериализацию маркера. Это позволяет включать представление маркера непосредственно в сообщение.

Ниже перечислены некоторые определенные в спецификации WS-Security маркеры безопасности:

  • маркер имени пользователя;

  • маркер сертификата X.509;

  • маркер Kerberos;

  • маркер SAML.

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

  • SignedSupporting

  • SignedEndorsing

  • SignedEncrypted

  • EncryptedEndorsing

В Платформа .NET Framework 3.0 клиентское сообщение может содержать только один маркер заданного типа, но может содержать маркеры различных типов.

В .NET Framework 3.5 клиентское сообщение может содержать несколько маркеров заданного типа, а также маркеры различных типов.

Это позволяет реализовывать различные сценарии, в том числе следующие.

  • Последовательная отправка утверждений. Для всех операций службы может требоваться набор утверждений, но для некоторых операций могут требоваться дополнительные утверждения. Вместо использования для каждой операции отдельных маркеров клиент может получить один маркер с базовым набором утверждений и другой маркер с оставшимися утверждениями, необходимыми для вызываемой операции.

  • Многофакторная проверка подлинности. Для получения разрешения на выполнение определенной операции клиенту может потребоваться собрать маркеры различных издателей или маркеры с различными наборами утверждений. Среда WCF полагает, что выданный маркер является типом маркера, поэтому для реализации этого сценария требуется возможность помещения в сообщение двух вспомогательных маркеров.

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

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

Реализация WS-Security

Поскольку в основе безопасности сообщений лежит спецификация WS-Security, ключевым элементом всего режима безопасности сообщений является реализация WS-Security в WCF. Чтобы расширить функциональность режима безопасности сообщений, необходимо понять, каким образом работает реализация WS-Security.

Реализация WS-Security в WCF отвечает за следующие операции:

  • сериализация маркеров безопасности в сообщения SOAP и обратно;

  • проверка подлинности маркеров безопасности;

  • применение и проверка подписей сообщений;

  • шифрование и расшифровка сообщения SOAP.

Точки расширяемости WCF позволяют настроить первые два элемента. Можно изменить сериализацию существующих маркеров безопасности и способ проверки подлинности этих маркеров системой безопасности WCF. Кроме того, можно реализовать в системе безопасности WCF совершенно новые типы маркеров безопасности, включая функции сериализации и проверки подлинности.

Далее в этом разделе показано, как можно с помощью точек расширяемости реализации WS-Security изменить функциональность маркеров безопасности.

Авторизация

Содержащиеся во входящих сообщениях маркеры безопасности десериализуются и проходят проверку подлинности. В процессе проверки подлинности создается набор объектов политики авторизации. Каждый из объектов представляет часть данных маркера безопасности. Эти данные используются на этапе авторизации.

Политика авторизации создает набор утверждений, представляемых данным маркером безопасности. Затем этот набор утверждений передается для принятия решений об авторизации в объект ServiceAuthorizationManager и в логику, заданную в свойстве AuthorizationContext.

Удостоверения

Помимо утверждений среда WCF создает реализацию интерфейса IIdentity, который представляет вызывающий объект существующей инфраструктуре (созданной с помощью модели безопасности .NET Framework). Эта реализация IIdentity представляет удостоверение Windows вызывающего объекта, если маркер безопасности сопоставлен с учетной записью Windows, или первичное удостоверение, содержащее имя вызывающего объекта. Доступ к этим удостоверениям также осуществляется с помощью объекта ServiceSecurityContext. (Дополнительные сведения см. в разделе Как анализировать контекст безопасности.) Настроить порядок создания удостоверений в WCF можно одним из следующих способов:

  • путем реализации пользовательского расширения класса SecurityTokenAuthenticator;

  • путем интеграции с ASP.NET за счет расширения класса MembershipProvider или создания пользовательской реализации IAuthorizationPolicy и ее подключения к объекту ServiceAuthorizationManager;

  • путем создания пользовательской политики IAuthorizationPolicy.

Пользовательский поставщик членства работает только в том случае, если для проверки подлинности вызывающего объекта используются имя пользователя и пароль. Поставщик MembershipProvider проверяет имя пользователя и пароль. Если имя пользователя и пароль действительны, среда WCF создает первичное удостоверение, которое представляет прошедший проверку подлинности вызывающий объект после проверки с помощью MembershipProvider.

Чтобы упростить интеграцию с имеющейся инфраструктурой безопасности .NET Framework, среда WCF по умолчанию задает в качестве значения свойства CurrentPrincipal экземпляр IPrincipal, представляющий вызывающий объект. Экземпляр IPrincipal создается на основе данных, которые содержатся в созданном объекте IIdentity.

IIdentity можно дополнительно расширить путем интеграции с ASP.NET RoleProvider. Объект RoleProvider добавляет набор ролей, относящихся к вызывающему объекту. Эти сведения используются в алгоритме авторизации для принятии решения о предоставлении доступа.

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

Отправка защищенных сообщений

На следующем рисунке показано, как обеспечивается защита сообщения на стороне клиента при использовании режима безопасности сообщений. На рисунке показано, какие компоненты участвуют в этом процессе, и отношения между этими компонентами.

  1. Запускается код приложения и создается сообщение.

  2. На этапе подготовки маркера прикрепляются учетные данные клиента (например, сертификат X.509). В федеративном сценарии к издателю маркера обращаются, чтобы он предоставил учетные данные.

  3. С помощью учетных данных создается маркер безопасности.

  4. На этапе проверки подлинности маркера маркеры проверяются.

  5. Наконец, маркеры безопасности сериализуются и отправляются.

Отправка защищенного сообщения

Получение защищенных сообщений

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

  1. На этапе проверки подлинности маркеров происходит десериализация и обработка маркеров безопасности. Если необходимо, для предоставления на данном этапе имен пользователей и паролей может использоваться поставщик членства ASP.NET.

  2. После проверки подлинности извлекаются политики авторизации.

  3. На этапе вычисления политик авторизации происходит вычисление политик авторизации, после чего утверждения добавляются в контекст вычисления. На этом этапе также используются внешние политики авторизации. Этот, а также следующий, этапы выполняются с помощью методов класса ServiceAuthorizationManager.

  4. На этапе авторизации службы на основе входящих в политики авторизации утверждений выдаются соответствующие разрешения. Этот этап выполняется с помощью методов класса ServiceAuthorizationManager.

  5. После авторизации выполняется олицетворение вызывающего объекта, если он разрешил олицетворение и оно требуется для выполнения метода службы, либо если задано свойство ImpersonateCallerForAllOperations поведения авторизации службы. Дополнительные сведения см. в разделе Делегирование и олицетворение с использованием WCF.

  6. На этом этапе среда WCF создает объект PrincipalPermission, используя учетные данные. Если необходимо, при этом используется поставщик ролей ASP.NET.

  7. Запускается код приложения.

Получение защищенного сообщения

Общие сведения о точках расширяемости безопасности

На следующем рисунке показаны точки расширяемости, предоставляемые компонентами безопасности WCF. Рисунок разделен на четыре категории в зависимости от того, в какой момент обработки сообщения достигается та или иная точка расширяемости. Эти категории соответствуют этапам обработки безопасности сообщений, описанным в двух предыдущих разделах. Кроме того, на рисунке показано, что с безопасностью WCF можно интегрировать существующие технологии инфраструктуры.

Точки расширяемости безопасности WCF

См. также

Справочник

PrincipalPermission
ServiceAuthorizationManager
ServiceSecurityContext

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

Архитектура Windows Communication Foundation
Делегирование и олицетворение с использованием WCF

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

Пользовательские учетные данные и проверка учетных данных