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

Частично доверенные размещения

Подход, представленный до сих пор для частично доверенных служб, был основан на коде, использующем AppDomainHost, выполняющийся в условиях полного доверия. Причина этого в том, что классу ServiceHost и привязкам требуется полное доверие в случае любого размещения, не входящего перечень из рис. 1.

А что, если запускаемый код является только частично доверенным? Можно было бы поместить AppDomainHost и ServiceHostActivator в сборку, обладающую полным доверием, разрешить частично доверенные вызывающие и предоставить им обоим полное доверие.

[PermissionSet(SecurityAction.Assert,Unrestricted = true)]
public class AppDomainHost : IDisposable
{...}
[PermissionSet(SecurityAction.Assert,Unrestricted = true)]
class ServiceHostActivator : MarshalByRefObject
{...}

Хотя этот подход дает результат, он обходит CAS и отключает жизненно важный механизм безопасности, что приводит к возникновению двух проблем безопасности. Во-первых, неправильно полагать, что код, открывающий размещение, обладает полномочиями на прием вызовов из транспортных каналов или на участие в каких-либо действиях WCF, таких как распределенные транзакции. Во-вторых, декларируя полное доверие и подавляя анализ стека, частично доверенный код, запустивший размещение, может на деле быть использован для создания службы с более высокими правами, чтобы она выполнила за него грязную работу. Например, размещающий код может не обладать полномочиями на ввод и вывод файлов, но он использует класс AppDomainHost для принятия вызовов к службе, имеющей полномочия на ввод и вывод файлов.

Решение является простым: классы AppDomainHost и ServiceHostActivator не должны использовать пустое утверждение полного доверия. Вместо этого, когда это необходимо, они должны его утверждать только локально, а затем возвращаться к существующим полномочиям. Кроме этого, класс AppDomainHost должен испытывать код, используя его, и запрашивать соответствующие полномочия размещения (например, принятие вызовов). Также он должен проверять факт предоставления размещающему коду по крайней мере тех полномочий, которые ему требуются для выполнения службы. Это предотвратит использование ограниченным и частично доверенным кодом службы, размещенной в отдельной области приложений и имеющей более широкие полномочия. В итоге мы получаем структурированные требования безопасности на стороне размещения.