Обычно значительно легче управлять безопасностью, если доступ к ресурсам и функциональности разрешается на основе полномочий, а не ролей. Представьте сценарий, где имеется три метода, каждый из них предоставляет доступ к свойству, для которого требуется строгий контроль, чтобы гарантировать, что только авторизованному персоналу доступ к нему открыт. Если приложение имеет, скажем, четырех пользователей, то достаточно легко определить в каждом методе, какие пользователи могут и какие не могут получить доступ к методу. Однако представим ситуацию, где число свойств возрастает до девяти. Чтобы разрешить доступ для дополнительного пользователя, потенциально потребуется изменить каждый из девяти методов, хотя это является административной задачей.
Даже хуже, так как пользователи меняются ролями в компании и понадобится изменять код каждый раз, когда это происходит. Если вместо этого реализовать систему, использующую роли, то можно просто добавлять и удалять пользователей из ролей, а не добавлять и удалять отдельных пользователей из приложения. Таким образом, выполнение приложения облегчается, и для каждого метода мы только ставим условие, чтобы пользователь был членом определенной группы. Ото также упрощает управление ролями, так как эту работу может делать администратор, а не разработчик приложения. Говоря проще, разработчик сосредоточивается на том, что, например, Managers, но не Secretaries, могут получить доступ к методу, а не на том, каковы возможности Julie и Bob, но не Conrad.
Система безопасности на основе ролей в .NET строится на системе безопасности из MTS и COM+ 1.0 и предоставляет гибкую среду, создающую ограждения вокруг разделов приложения, которые должны быть защищены. Если система COM+ 1.0 установлена на машине, ее безопасность на основе ролей будет интерпретироваться в NET, однако COM не требуется .NET на основе ролей для функционирования системы безопасности.
Принципал Windows
Создадим консольное приложение, предоставляющее доступ к принципалу в приложении. в котором мы хотим пользоваться описанной ниже учетной записью Windows. Нам необходимы пространства имен
System.Security.Principal
и
System.Threading
. Прежде всего нужно задать, что мы хотим, чтобы .NET автоматически соединял принципал с описанной ниже учетной записью Windows, так как в .NET это не происходит автоматически по соображениям безопасности. Наше задание:
using System;
using System.Security.Principal;
using System.Security.Permissions;
using System.Threading;
namespace SecurityApplication2 {
class Class1 {
static void Main(string[] args) {
AppDomain.CurrentDomain.SetPrincipalPolicy(
PrincipalPolicy.WindowsPrincipal);
Можно использовать метод
WindowsIdentity.GetCurrent
для доступа к данным учетной записи Windows, однако такой способ подходит, когда необходимо взглянуть на принципал один раз. Если необходимо обратиться к принципалу несколько раз, то более эффективно задать политику так, чтобы текущий поток выполнения предоставлял доступ к принципалу. При использовании метода
SetPrincipalPolicy
определяется, что принципал в текущем потоке выполнения должен поддерживать объект
WindowsIdentity
. Добавим код для доступа к свойствам принципала из объекта
из этого консольного приложения будет выглядеть похожим на следующий, в зависимости от конфигурации машины и ролей, ассоциированных с учетной записью, под которой вы зарегистрировались в системе:
Очевидно, что крайне полезно иметь возможность получить так легко доступ к данным о текущем пользователе и его ролях, чтобы с помощью этой информации решать, какие действия выполнить и какие отменить. Роли и группы пользователей Windows предоставляют администраторам дополнительную возможность использовать стандартные утилиты администрирования пользователей, и обычно можно избежать изменения кода, когда изменяются роли пользователя. Рассмотрим роли более подробно.
Роли
Представим сценарий, где имеется приложение интранет, использующее учетные записи Windows. Система имеет группу
Manager
и группу
Assistant
, пользователи относятся к этим группам в зависимости от их роли в организации. Пусть приложение содержит свойство, выводящее информацию о сотрудниках, и желательно, чтобы к нему имела доступ только группа
Manager
. Можно легко применить код, который проверяет, является ли текущий пользователь членом группы
Manager
, и разрешать или запретить ему доступ на основе этого.
Однако, если в дальнейшем будет решено реорганизовать группы учетных записей и ввести группу
Personnel
, которая также имеет доступ к данным о сотрудниках, то возникнет проблема. Придется просмотреть весь код и обновить его, чтобы включить правила для этой новой группы.
Лучшим решением было бы создание полномочия, называемого, предположим,
ReadEmployeeDetails
, и присваивание его группам, где необходимо. Если код проверяет полномочие
ReadEmployeeDetails
, то обновление приложения с целью разрешить группе
Personnel
доступ к данным о сотрудниках, является просто вопросом создания группы, внесения в нее пользователей и присваивание группе полномочия
ReadEmployeeDetails
.
Система безопасности на основе декларативной роли
Так же, как в случае с системой безопасности доступа к коду, можно реализовать запросы безопасности на основе ролей ("пользователь должен быть в группе Administrators"), используя обязательные запросы (см. предыдущий раздел), или использовать атрибуты. Возможно декларативное определение требований к полномочию на уровне класса в таком виде:
