Создание собственных разрешений доступа к коду
Обновлен: Ноябрь 2007
.NET Framework предоставляет набор классов разрешений доступа к коду для защиты определенного ряда ресурсов и операций, в первую очередь ресурсов, предоставляемых средой .NET Framework. Эти классы разрешений кратко описаны в разделе Разрешения и более подробно — в справочных сведениях по каждому классу разрешения. Для большинства сред достаточно встроенных разрешений на доступ для кода. Однако в некоторых ситуациях может иметь смысл определить собственный класс разрешений на доступ для кода. В данной теме обсуждается, когда, зачем и как определять пользовательские классы разрешений доступа к коду.
Если необходимо определить компонент или библиотеку классов, осуществляющие доступ к ресурсу, который не подпадает под какой-либо встроенный класс разрешений, но должен быть защищен от неавторизованного кода, следует рассмотреть возможность создания собственного класса разрешения доступа к коду. Если необходимо обеспечить возможность заявлять декларативные требования для пользовательского разрешения, необходимо также определить класс атрибута для этого разрешения. Подготовка этих классов и заявление требований разрешения из библиотеки классов позволяет среде выполнения предотвращать доступ неавторизованного кода к этому ресурсу и позволяет администратору настраивать права доступа.
Возможны и другие ситуации, когда использование пользовательского разрешения может быть уместно. Пользовательское разрешение может понадобиться, когда встроенный класс разрешения доступа к коду защищает ресурс, но в недостаточной мере контролирует доступ к нему. Например, приложение может использовать записи о персонале, каждая из которых хранится в отдельном файле; в этом случае доступ на чтение и запись может управляться независимо для разных типов данных о сотрудниках. Внутреннему инструменту управления может быть разрешено чтение определенных секций файла персонала, но не разрешено производить запись в эти секции. На деле ему даже может быть запрещено чтение некоторых секций.
Пользовательские разрешения доступа к коду также уместны в случаях, когда существует встроенное разрешение, но оно не определено в виде, позволяющем защищать ресурс требуемым образом. Например, возможна ситуация, когда существует некоторая функциональность пользовательского интерфейса, такая как способность создавать меню, которая должна быть защищена, но не защищается встроенным классом UIPermission. В этом случае можно создать пользовательское разрешение с целью защитить способность создавать меню.
Если это возможно, разрешения не должны перекрываться. Наличие более чем одного разрешения, защищающего ресурс, представляет серьезную проблему для администраторов, которым придется соответствующим образом следить за всеми перекрывающимися разрешениями каждый раз при настройке прав на доступ к этому ресурсу.
Создание пользовательского разрешения доступа к коду включает следующие шаги, некоторые из которых являются необязательными. Каждый шаг описан в отдельном разделе.
Реализуйте интерфейсы IPermission и IUnrestrictedPermission.
Если это необходимо из соображений производительности или поддержки специальных типов данных, реализуйте интерфейс ISerializable.
Обеспечьте обработку кодирования и декодирования XML.
Добавление поддержки декларативной безопасности путем определения класса Attribute.
Требование пользовательского разрешения для вашего разрешения в соответствующем месте.
Обновление политики безопасности для поддержки пользовательского разрешения.
См. также
Основные понятия
Добавление поддержки декларативной безопасности
Требование пользовательского разрешения
Обновление политики безопасности