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

Создадим консольное приложение, предоставляющее доступ к принципалу в приложении. в котором мы хотим пользоваться описанной ниже учетной записью 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:MACHINE\alaric

'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 {

class Class1 {

static void Main(string[] args) {

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);

try {

ShowMessage();

} catch (SecurityException exception) {

Console.WriteLine(

"Security exception caught (" + exception.Message + ")");

Console.WriteLine(

"The current principal must be in the local"

+ "Users group");

}

}

(PrincipalPermissionAttribute(SecurityAction.Demaid, Role =

"BUILTIN\\Users"));

static void ShowMessage() {

Console.WriteLine("The current principal is longed in locally");

Console.WriteLine("they are a member of the local Users group)");

}

}

}

Метод ShowMessage()будет порождать исключение, если приложение выполняется не в контексте пользователя из группы локальных Users в Windows 2000. Что касается приложений Web, то учетная запись, под которой выполняется код ASP.NET, должна быть в группе, хотя в реальном мире определенно будут избегать добавления этой учетной записи в группу администраторов.

Если выполнить приведенный выше код с помощью учетной записи в локальной группе Users, то вывод будет таковым:

The current principal is logged in locally

(they are a member of the local Users group)

Дополнительную информацию о системе безопасности на основе ролей в .NET можно найти в документации MSDN для пространства имен System.Security.Principal.

Аспекты безопасности .NET разработаны значительно полнее и шире, чем какие-либо другие вопросы в Windows, но все же есть и которые ограничения, о которых необходимо знать:

□ Политика системы безопасности .NET не обеспечивает безопасность на неуправляемом коде (хотя обеспечивает некоторую защиту от обращении к неуправляемому коду).

□ Если пользователь копирует сборку на свою локальную машину, сборка имеет полномочия FullTrustи, таким образом, политика безопасности не действует. Чтобы решить эту проблему, можно ограничить полномочия предоставляемые локальному коду.

□ Политик системы безопасности .NET предоставляет очень небольшую помощь при борьбе со злонамеренными файлами .ЕХЕ Win32 и вирусами на основе сценариев, с которыми Microsoft борется различными способами. Например недавние версии Outlook не позволяют обрабатывать исполнимые файлы из почтовых сообщений, пользователь предупреждается, что они могут содержать вирусы, и сохраняет их на диске, где имеются возможности для установки административных ограничений, включая блокирование доступа к локальному диску и работу антивирусного программного обеспечения.