Разграничение доступа из кода в WCF - Необработанные требования WCF

Необработанные требования WCF

Более учитывающее безопасность использование PartialTrustClientBase<T> – это не дать прокси установить полное доверие:

public class MyContractClient : 
  PartialTrustClientBase<IMyContract>,IMyContract
{
  public MyContractClient() {}
  public MyContractClient(string endpointName) : 
   base(endpointName) {}
  public void MyMethod() {
   Channel.MyMethod();
  }
}

Чтобы поддержать это, PartialTrustClientBase<T> точечно подтверждает полное доверие для своих конструкторов и своего метода Close. Вдобавок, PartialTrustClientBase<T> скрывает свойство Channel класса ClientBase<T> и устанавливает полное доверие на методе получения. Этого достаточно, чтобы подавить требование полного доверия со стороны привязки WCF, поскольку это требование выдается при конструировании прокси, а также при открытии и закрытии его канала, но не при собственно использовании. Интересным эффектом структурирования прокси таким образом является открытие кода клиента необработанным требованиям безопасности WCF – то есть всем требованиям безопасности, требуемым для передачи вызова службе!

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

Если клиент желает использовать безопасность Windows и отправить интерактивное удостоверение пользователя, то прокси потребует полномочие среды на доступ к переменной USERNAME. Если клиент желает отправить альтернативные учетные данные Windows, то прокси потребует полномочие безопасности на управление участником. Если клиент желает отправить вызов асинхронно или получить дуплексные обратные вызовы, то прокси потребует полномочие на управление политикой и доказательством (и то и другое является флагами полномочия безопасности, требуемыми при «прыжках» вызовов между потоками). Если клиент желает использовать надежный обмен сообщениями, то прокси потребует также и контроля над политикой. Если клиент использует защиту сообщений с помощью учетных данных имени пользователя и согласования сертификата службы, но без проверки согласованного сертификата службы, прокси также потребует полномочия на управление политикой и доказательством. Если клиент использует возможности диагностики и отслеживания WCF, то прокси потребует доступа к переменной среды COMPUTERNAME (чтобы иметь возможность отслеживать ее) и доступ неуправляемого кода (предположительно для доступа к файлам журнала, так что это должно было бы быть полномочие на ввод/вывод).

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

Определенные возможности WCF также без затей переходят к требованиям полного доверия, несмотря на наличие отлично подходящих типов полномочий. Любая попытка распространить транзакцию требует полного доверия (вместо использования полномочия распределенной транзакции), равно как и любой доступ к хранилищу сертификатов (вместо использования полномочия хранилища сертификатов). На рис. 3 показаны необработанные требования безопасности WCF, вызываемые кодом, вроде моего последнего варианта PartialTrustClientBase<T>, когда привязкам установлены их параметры по умолчанию для нескольких ключевых случаев, таких как транзакции, надежность, диагностика, асинхронные вызовы, доступ к хранилищу сертификатов и защита сообщений.

Рис. 3 Необработанные клиентские требования безопасности WCF

Из всех привязок доступа неуправляемого кода не требуют только основные и веб-привязки. Привязка WS по умолчанию принимает параметры защиты сообщений по умолчанию, приводя к требованию полномочия на доступ неуправляемого кода.