Роли .NET в Windows

Чтобы не проверять каждое имя пользователя, вы можете назначить пользователям те или иные роли Затем можно проверять, принадлежит ли пользователь к определенной роли или нет Примером применения ролей является стандартная группа администраторов Вам не нужно присваивать личности пользователя все полномочия администратора по отдельности, а затем проверять, есть ли у конкретных пользователей те или иные полномочия. Вы просто зачисляете пользователя в группу администраторов И тогда ваш код может проверять, находится ли пользователь в группе администраторов, прежде чем дать ему возможность, например, создать нового пользователя. Надо сказать, что роли .NET отличаются от ролей СОМ+.
Роли в NT4 и Wmdows2000 задаются путем определения групп. Каждая группа представляет какую-либо роль. Перейдите на Control Panel (Панель управления) и выберите команду Administrative Tools (Инструменты администрирования). В списке Administrative Tools (Инструменты администрирования) выберите пункт Computer Management (Управление компьютером). Появится окно дополнительного модуля Computer Management (Управление компьютером), присоединенного к консоли ММС. В этом окне разверните узел Local Users and Groups (Локальные пользователи и группы). Как показано на рис. 13.1, при выборе узла Groups (Группы) вы увидите все группы, определенные на вашей машине. К ним была добавлена группа CustomerAdmm.
Некоторые группы, такие, например, как Administrators (Администраторы) и Guests (Гости), являются встроенными, потому что были для вас заранее определены. Что же касается группы CustomerAdmm, то она определена пользователем. В эту группу входят все администраторы, которые имеют право изменять информацию пользователя Acme
Чтобы добавить на локальную машину новую группу, щелкните правой кнопкой мыши на узле Groups (Группы), а затем выберите команду New Group (Добавление группы). Появится диалоговое окно, которое вам предстоит заполнить.

Рис. 13.1. Группы, определенные в машине

Это диалоговое окно, уже заполненное данными для создания новой группы Hote-lAdmin, показано на рис. 13.2. В группу HotelAdmin должны входить все пользователи машины, которые могут добавлять или изменять информацию о гостиницах в системе HotelBroker. Чтобы добавить группу в систему, надо щелкнуть на кнопке Create (Создать). Добавление пользователей в систему или их удаление из нее выполняется, соответственно, с помощью кнопок Add (Добавить) и Remove (Удалить).
Чтобы внести изменения в существующей группе, выделите ее, щелкните на ней правой кнопкой мыши и выберите команду Properties (Свойства). Щелкнув на кнопке Add (Добавить), вы получите диалоговое окно со всеми пользователями системы. Теперь можно выбирать нужных пользователей и добавлять их в группу. На рис. 13.3 показано добавление пользователя в группу HotelAdmin. Обратите внимание, что JaneAdmm и Ре-terT— это ранее созданные и настроенные учетные записи пользователей. Удаление пользователей из группы выполняется с помощью кнопки Remove (Удалить).

Рис. 13.2 Диалоговое окно, в котором создается группа HotelAdmin

В программе имя роли надо указывать, используя имя домена или машины. На моей машине роль CustomerAdmm обозначается как "HPDESKTOP\\CustomerAdmm", а роль HotelAdnun — как "HPDESKTOP\\HotelAdmin". Для заранее установленных групп используется префикс "BUILTIN" ("ВСТРОЕННЫЙ"), например, встроенная группа Administrators (Администраторы) обозначается как "BUILTIN\\Admmistrators" ("ВСТРОЕН-НЫЕ\\Администраторы"). Чтобы избежать проблем, связанных с переводом и интернационализацией, для обращения к встроенным ролям используется перечисление System::Security::Principal::WindowsBuiltlnRole (Система .Защита::Прин-ципал-'WindowsBuiltInRole). Вместо того, чтобы использовать строку "BUILTIN\\Admi-nistrators" ("ВСТРОЕННЫЕ\\Администраторы"), группу Administrators (Администраторы) можно обозначать как WindowsBuiltlnRole: :Administrator (Wmdows - Администратор).

Рис. 13.3. Добавление в группу пользователя JaneAdmin Уже добавлен пользователь PeterT

Пример RoleBasedSecurity, который мы рассматривали в предыдущем разделе, на этот раз проверяет, имеет ли текущий пользователь несколько ролей Вы можете передавать роль в виде строки или использовать перечисление WindowsBuiltlnRole Помните, что необходимо изменить программу, чтобы использовать фактическое имя вашей машины, когда вы выполняете пример на вашем компьютере Для выбора ветвей кода, соответствующих членству в этих ролях, в программе используется оператор условного перехода if-else

// использовать роль, чтобы выбрать ветвь кода
String *adminRole = "HPDESKTOP\\CustomerAdmin"; // Строка
if(wp->Is!nRole(adminRole))
{
Console.:WriteLine(
"In Customer Administrator role."); // "В роли Администратора." // выбрать ветвь кода для CustomerAdmin... }
else {
Console::WriteLine(
"Not in Customer Administrator role."); // "He в роли Администратора." // не выбирать ветвь кода для CustomerAdmin... }
// использование встроенных ролей для выбора ветви кода if(wp->Is!nRole(WindowsBuiltlnRole::Administrator)) // если Администратор {
Console::WriteLine(
"In Administrator role");
// "В роли Администратора"
// выбрать ветвь кода для Администратора... }
else {
Console::WriteLine(
"Not in Administrator role."); // "He в роли Администратора." // не выбирать ветвь кода для Администратора...
}
if(wp->Is!nRole(WindowsBuiltlnRole::Guest))
// если Гость
{
Console::WriteLine( "In Guest role"); // "В роли Гостя"
// выбрать ветвь кода для Гостя... }
else {
Console::WriteLine(
"Not in Guest role."); // "He в роли Гостя." //не выбирать ветвь кода для Гостя...
}
if(wp->Is!nRole(WindowsBuiltlnRole::User))
// если Пользователь
{
Console::WriteLine(
"In User role");
// "В роли Пользователя" // выбрать ветвь кода для Пользователя...
}
else
{
Console::WriteLine (
"Not in User role"); // "He в роли Пользователя"
// не выбирать ветвь кода для Пользователя... }

Если вы зарегистрировались как Administrator (Администратор), то при выполнении примера RoleBasedSecurity получится следующий вывод

Demanding right to change principal policy
AppDomain Principal Policy changed to WindowsPrincipal
Thread::CurrentPrincipal is a WindowsPrincipal
Thread::CurrentPrincipal Name: HPDESKTOPXAdministrator
Type: NTLM IsAuthenticated: True
WindowsPrincipal Identity Name: HPDESKTOPXAdministrator
Type: NTLM Authenticated: True Token: 260
Name matches HPDESKTOPXAdministrator
In Customer Administrator role
In Administrator role
Not in Guest role
In User role

Перевод такой:

Требование права изменять политику принципала
Политика принципала AppDomain заменена WindowsPrincipal
Поток:: CurrentPrincipal - WindowsPrincipal
Поток:: CurrentPrincipal Имя HPDESKTOP\Administrator
Тип: NTLM IsAuthenticated: Истина
Имя личности WindowsPrincipal: HPDESKTOP\Administrator
Тип: Заверен NTLM: Истинная Лексема: 260
Имя совпадает с HPDESKTOPXAdministrator
В роли Клиентского Администратора
В роли Администратора
Не в роли Гостя
В роли Пользователя

Ну а если вы зарегистрировались как JaneAdmin, то при выполнении RoleBasedSecurity вывод будет следующий:

Demanding right to change principal policy
AppDomain Principal Policy changed to WindowsPrincipal
Thread::CurrentPrincipal is a WindowsPrincipal
Thread::CurrentPrincipal Name: HPDESKTOP\JaneAdmin Type:
NTLM IsAuthenticated: True
WindowsPrincipal Identity Name: HPDESKTOPXJaneAdmin Type:
NTLM Authenticated: True Token: 260
Name does not match HPDESKTOPXAdministrator
Not in Customer Administrator role.
Not in Administrator role.
Not in Guest role.
In User role

Перевод такой:

Требование права изменять политику принципала
Политика принципала AppDomain заменена WindowsPrincipal
Поток:: CurrentPrincipal - WindowsPrincipal
Поток:: CurrentPrincipal Имя: HPDESKTOPXJaneAdmin Тип:
NTLM IsAuthenticated: Истина
Имя личности WindowsPrincipal: HPDESKTOPXJaneAdmin Тип:
NTLM Заверен: Истинная Лексема: 260
Имя не совпадает с HPDESKTOPXAdministrator
Не в роли Клиентского Администратора.
Не в роли Администратора.
Не в роли Гостя.
В роли Пользователя