Разграничение доступа из кода в WCF - CAS на стороне размещения в .NET Framework 3.5
ОГЛАВЛЕНИЕ
CAS на стороне размещения в .NET Framework 3.5
В среде .NET Framework 3.5 WCF разрешает размещать службу посредством привязок BasicHttpBinding, WSHttpBinding и WebHttpBinding только частично доверенному коду и только безо всякой безопасности или с безопасностью передачи данных. Более того, в случае WSHttpBinding не разрешаются такие аспекты, как безопасность сообщений, надежный обмен сообщениями и транзакции. Все привязки со включенным частичным доверием должны использовать текстовое кодирование. Служба, выполняющаяся в условиях частичного доверия, не может использовать дополнительные средства, такие как диагностика и счетчики производительности.
Принудительное применение ограниченного набора поддерживаемых функций является обязанностью привязок. Каждая привязка, кроме привязок HTTP, активно требует полного доверия от размещения службы. Разрешенные привязки HTTP не требуют полного доверия; вместо этого они требуют полномочий в соответствии с контекстом использования, как показано на рис. 1.
Рис. 1 Требования разрешенных привязок HTTP на размещении
| Случай | Полномочия |
|---|---|
| Basic, веб- и WS- безо всякой безопасности или с безопасностью транспорта | Полномочие безопасности с исполнением и инфраструктурой; веб-полномочие для приема вызовов к идентификатору URI. |
| Вышеупомянутые привязки с внутренним типом службы в отдельной сборке | Неограниченное отражение. |
| Вышеупомянутые привязки с проверенными на подлинность вызовами | Полномочие безопасности на управление участником. |
Все разрешенные привязки HTTP требуют полномочия на выполнение и полномочия на изменение инфраструктуры (полномочие безопасности с флагом инфраструктуры), а также полномочие на прием вызовов на идентификаторе URI, настроенном на их конечную точку (веб-полномочие с флагом приема для идентификатора URI). При проверке подлинности вызовов разрешенные привязки HTTP требуют также полномочия на управление участником потока (полномочие безопасности с флагом управления участником).
Это сделано по той причине, что после проверки подлинности WCF установит нового участника с удостоверением, соответствующим предоставленным клиентом учетным данным для длительности вызова, и невзирая на привязку. Если тип службы, предоставленный конструктору приложения, определен как внешний тип другой сборки, размещение также требует неограниченного полномочия на отражение, чтобы быть в состоянии загружать этот тип с помощью отражения. (Решение о требовании полномочия на инфраструктуру озадачивает, поскольку никакой очевидной необходимости в нем нет.)
Существуют дополнительные ограничения настройки, которые необходимо учитывать. Например, файл .config не может содержать никаких ссылок на какие-либо хранилища сертификатов (для серверных сертификатов), поскольку контакт с хранилищем сертификатов заставит WCF потребовать полного доверия. Администраторы должны настраивать эти сертификаты раздельно, используя такие средства, как HttpConfig.exe.
У обоснования требования полномочий на стороне размещения только привязкой имеется тот недостаток, что размещаемому экземпляру службы эти полномочия даются неявным образом, даже если они ему не требуются для функционирования. Например, экземпляр службы мог бы управлять участником или отражать внутренние типы других сборок на основном компьютере. Предпочтительнее было бы проектировать привязки для требования полномочий и все-таки каким-нибудь образом обеспечивать размещениб способ предоставления различных полномочий службе таким образом, чтобы полномочия службы были подмножеством полномочий приложения, в котором она размещена.
В идеале хорошо было бы задействовать все возможности WCF, начиная от распределенных транзакций до надежных вызовов, различных типов учетных данных безопасности, связи приложений в интрасети (или даже на одном компьютере) через TCP, а также каналов межпроцессного взаимодействия (IPC), таких как именованные каналы, не говоря уже о дуплексных обратных вызовах, асинхронных вызовах, диагностике и трассировке, инструментировании и, безусловно, очереди вызовов посредством Microsoft Message Queue (MSMQ). Хотелось бы добиться всего этого, не жертвуя CAS, то есть не прибегая к полному доверию.