|
Роли .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
Не в роли Клиентского
Администратора.
Не в роли Администратора.
Не в роли Гостя.
В роли Пользователя
|
