C# для профессионалов. Том II

и предоставляет гибкую среду, создающую ограждения вокруг разделов приложения, которые должны быть защищены. Если система 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. Добавим код для доступа к свойствам принципала из объекта Thread:

   WindowsPrincipal principal =
   (WindowsPrincipal)Thread.CurrentPrincipal;
   WindowsIdentity identity = (WindowsIdentity)principal.Identity;
   Console.WriteLine('IdentityTyрe:' + identity.ToString());
   Console.WriteLine('Name:' + identity.Name);
   Console.WriteLine(
    'Users'?:' + principal.IsInRole('BUILTIN\Users'));
   Console.WriteLine(
    'Administrators' ?: ' +
    principal.IsInRole(WindowsBuiltInRole.Administrator));
   Console.WriteLine('Authenticated:' + identity.IsAuthenticated);
   Console.WriteLine('AuthType:' + identity.AuthenticationType);
   Console.WriteLine('Anonymous?:' + identity.IsAnonymous);
   Console.WriteLine('Token:' + identity.Token);
  }
 }
}

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

IdentityType:System.Security.Principal.WindowsIdentity
Name:MACHINEalaric
'Users'?:True
'Administrators'?:True
Authenticated:True
AuthType:NTLM
Anonymous?:False
Token:256

Очевидно, что крайне полезно иметь возможность получить так легко доступ к данным о текущем пользователе и его ролях, чтобы с помощью этой информации решать, какие действия выполнить и какие отменить. Роли и группы пользователей Windows предоставляют администраторам дополнительную возможность использовать стандартные утилиты администрирования пользователей, и обычно можно избежать изменения кода, когда изменяются роли пользователя. Рассмотрим роли более подробно.

Роли

Представим сценарий, где имеется приложение интранет, использующее учетные записи Windows. Система имеет группу Manager и группу Assistant, пользователи относятся к этим группам в зависимости от их роли в организации. Пусть приложение содержит свойство, выводящее информацию о сотрудниках, и желательно, чтобы к нему имела доступ только группа Manager. Можно легко применить код, который проверяет, является ли текущий пользователь членом группы Manager, и разрешать или запретить ему доступ на основе этого.

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

Лучшим решением было бы создание полномочия, называемого, предположим, ReadEmployeeDetails, и присваивание его группам, где необходимо. Если код проверяет полномочие ReadEmployeeDetails, то обновление приложения с целью разрешить группе Personnel доступ к данным о сотрудниках, является просто вопросом создания группы, внесения в нее пользователей и присваивание группе полномочия ReadEmployeeDetails.

Система безопасности на основе декларативной роли

Так же, как в случае с системой безопасности доступа к коду, можно реализовать запросы безопасности на основе ролей ('пользователь должен быть в группе Administrators'), используя обязательные запросы (см. предыдущий раздел), или использовать атрибуты. Возможно декларативное определение требований к полномочию на уровне класса в таком виде:

using System;
using System.Security;
using System.Security.Principal;
using System.Security.Permissions;
namespace SecurityApp3 {