Класс SecurityPermission
Класс SecurityPermission управляет "метаразрешениями", которые, в свою очередь, управляют подсистемой защиты общеязыковой среды выполнения CLR. Давайте снова обратимся к примеру RoleBasedSecurity, который уже рассматривали в этой главе. В нем с помощью метода AppDomain::SetPrincipalPolicy задавалась политика принципалов для прикладных областей:
AppDomain *ap = AppDomain::CurrentDomain; ap › SetPrincipalPolicy( PrincipalPolicy::WindowsPrincipal);
Тип принципала, возвращаемый Thread::CurrentPrincipal, будет зависеть от политики принципалов прикладной области. В перечислении System::Security::PrincipalPolicy определены следующие три политики опознавания для прикладной области:
- WindowsPrincipal применяет текущего пользователя, связанного с потоком. Thread::CurrentPrincipal возвращает объект WindowsPrincipal;
- UnauthenticatedPrincipal применяет неаутентифицированного пользователя. Thread::CurrentPrincipal возвращает объект GenericPrincipal. Это политика, задаваемая по умолчанию;
- NoPrincipal возвращает пустой указатель (null) для Thread::CurrentPrincipal.
Политику можно задавать с помощью метода SetPrincipalPolicy экземпляра AppDomain, относящегося к текущей прикладной области. Статический метод AppDomain::CurrentDomain вернет текущий экземпляр. Этот метод должен вызываться перед любым вызовом Thread::CurrentPrincipal. Дело в том, что объект принципала не создается до первой попытки доступа к этому свойству.
Чтобы при выполнении примера RoleBasedSecurity можно было задавать политику принципалов, у него должно быть право ControlPrincipal. С целью убедиться, что выполняемый код имеет такое право, перед изменением политики можно вызвать метод Demand (Требование) объекта SecurityPermission. Если у вас нужного разрешения нет, то будет запущено исключение SecurityException.
SecurityPermission *sp = new SecurityPermission(SecurityPermissionFlag::ControlPrincipal);
try
{
// Проверить, имеют ли все вызывающие программы выше в стеке
// вызовов разрешение управлять
// объектом принципала перед выполнением действий над ним.
sp › Demand();
}
catch(SecurityException *se)
{
// не может управлять объектом принципала
Console::WriteLine(se › Message); // Сообщение
return;
}
Сначала мы создаем новый экземпляр SecurityPermission, передавая конструктору нужное нам разрешение защиты, чтобы видеть, имеем ли мы право использовать это разрешение. SecurityPermissionFlag– это перечисление разрешений, используемых классом SecurityPermission. Разрешение ControlPolicy предоставляет право изменять политику. Очевидно, такое право должно быть предоставлено только проверенному коду. Затем мы требуем (запрашиваем) само разрешение.
Как уже говорилось, вы можете утверждать только те разрешения, которыми ваша сборка действительно обладает. Поэтому жульнические компоненты при выполнении в вашем коде не смогут просто так утверждать разрешения. Вы можете либо задавать политику безопасности, либо с помощью класса SecurityPermission запретить компонентам вызывать метод Assert (Утвердить). Создайте экземпляр этого класса со значением SecurityPermissionFlag::Assertion, а затем примените к разрешению метод Deny (Запретить).
Есть и другие действия, которые можно контролировать с помощью класса SecurityPermission. Среди них укажем следующие: создание прикладных областей и управление этими областями, задание политики, разрешение или запрещение выполнения, слежение за выполнением проверки правильности, а также получение доступа к неуправляемому коду.