Исходники.Ру - Программирование
Исходники
Статьи
Книги и учебники
Скрипты
Новости RSS
Магазин программиста

Главная » Статьи по программированию » .NET - Все статьи »

Обсудить на форуме Обсудить на форуме

Управление доступом на основе ролей с помощью Authorization Manager в Windows Server 2003
Описывается создание, поддержка и управление приложениями, основанными на ролях, c использованием Authorization Manager и связанной с ним MMC-оснасткой AzMan. Дано введение в управление доступом на основе ролей и связанная с ним терминология, а также описание процесса создания ролей, заданий и операций, выполняемых над используемыми ресурсами.

Аннотация

Описывается создание, поддержка и управление приложениями, основанными на ролях, c использованием Authorization Manager и связанной с ним MMC-оснасткой AzMan. Дано введение в управление доступом на основе ролей и связанная с ним терминология, а также описание процесса создания ролей, заданий и операций, выполняемых над используемыми ресурсами.

Содержание

Введение
Модель авторизации пользователей в Windows NT 4.0 и Windows 2000
Управление доступом на основе ролей
Хранилище, используемое при авторизации
Процесс разработки приложений, использующих Authorization Manager
Заключение

Введение

Для выполнения назначенных заданий приложения должны поддерживать операции и обращаться к ресурсам системы от имени пользователя, одновременно защищая эти операции и ресурсы от неавторизованного доступа. В операционных системах Microsoft Windows NT, Windows 2000 и Windows XP администраторы могут разрешать или запрещать процессам обращаться к защищаемым объектам или выполнять различные административные задания. Управление полномочиями основано на объектной модели авторизации, использующей списки управления доступом (access control lists, ACL). С каждым системным объектом связан список доверяемых сущностей (пользовательских и групповых учетных записей или сеансов регистрации) с конкретным набором прав для этого объекта. Эта модель хорошо зарекомендовала себя в защите четко определенных и постоянных ресурсов. Однако ACL неудобны в приложениях других типов, например в тех, которые ограничивают доступ к неким бизнес-процессам.

В Windows Server 2003 появился дополнительный авторизующий интерфейс, называемый Authorization Manager, который включает управление доступом на основе ролей. Authorization Manager предоставляет естественную инфраструктуру для приложений бизнес-процессов, которым требуется представлять организационную модель в инфраструктуре защиты приложения. Новый набор API и средств управления упрощает архитектуру и управление защитой в приложениях таких типов.

Модель авторизации пользователей в Windows NT 4.0 и Windows 2000

Windows NT и Windows 2000 предоставляют объектную модель авторизации. Диспетчер ресурсов (resource manager, RM) управляет собственным набором объектов, защищаемых дескриптором защиты. Когда клиент запрашивает доступ к ресурсу, защищаемому RM, последний подменяет клиент и вызывает API-функцию AccessCheck. В свою очередь она анализирует маркер защиты (security token) клиента, запрошенный уровень доступа и дескриптор защиты объекта. AccessCheck отвечает RM "да" или "нет", позволяя последнему принять решение о запрете или разрешении доступа.

Эта объектная модель проста, но ограниченна. Она дает ответы на вопросы типа "Что можно сделать с этим объектом?" и в то же время не способна ответить на вопрос "Что пользователь может делать в этом приложении?". Такие модели требуют, чтобы администраторы перевели организационную модель компании в права на объекты, где каждый объект имеет список прав доступа, выданных различным пользователям и группам в организации. Чтобы разработчик мог поддерживать определенную роль приложения, ему придется перечислить все объекты в системе и выдать соответствующие права на доступ пользователю. Более того, разрешения для объекта - очень низкоуровневые (например контроль чтения или обратная запись), и зачастую их нелегко перевести в высокоуровневые абстракции.

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

Управление доступом на основе ролей

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

При управлении доступом на основе ролей разрешения выдаются не посредством низкоуровневых прав, а высокоуровневых абстракций, соответствующих операциям и заданиям приложения. Операции являются неделимыми единицами, тогда как задания могут состоять из нескольких операций (и других заданий). Рассмотрим приложение-пример, позволяющее пользователям отчитываться о статусе проекта, публиковать статус и просматривать его. Эти действия осуществляются через Web-интерфейс. При публикации обновляется база данных и отсылается письмо всем заинтересованным лицам. На рис. 1 дан пример использования низкоуровневых операций для создания высокоуровневых заданий из нашего примера.

{
Надписи на рисунке:
Report status - Отчет о статусе
Publish status - Публикация статуса
View status - Просмотр статуса
Database operation - Операция с базой данных
Web operation - Web-операция
Mail operation - Операция с почтой
}

Рис. 1. Низкоуровневые операции образуют высокоуровневые задания

В ролевой модели управления доступом роль - это интерфейс, через который администратор управляет разрешениями и назначениями. Например, в компании может быть роль "Инженер", определенная с точки зрения полномочий, необходимых инженерам для их работы. Каждому принимаемому на работу инженеру назначается роль "Инженер" и он сразу же получает все необходимые права. Аналогично инженеры, увольняемые с этой должности, исключаются из роли "Инженер" и теряют права на доступ. Так как роли дают доступ с точки зрения организационной модели компании, администраторам проще и удобнее управлять доступом. Хотя ACL хорошо работают для четко определенных, постоянных ресурсов, ролевая модель очень удобна для защиты рабочих процессов или групп из нескольких различных операций (например "прочесть данные из базы" или "отправить почту"), выполняемых приложением. На рис. 2 предыдущий пример раскрывается и демонстрируются роли "Инженер" (Engineer) (позволяет отчитываться о статусе и просматривать его), "Менеджер" (Manager) (позволяет публиковать и просматривать статус) и "Руководитель" (Executive) (позволяет просматривать статус).

{
Надписи на рисунке:
Engineer
Manager
Executive
Report status - Отчет о статусе
Publish status - Публикация статуса
View status - Просмотр статуса
Database operation - Операция с базой данных
Web operation - Web-операция
Mail operation - Операция с почтой
}

Рис. 2. Схема управления доступом на основе ролей

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

Ролевое управление доступом в Windows Server 2003 тоже позволяет объединять пользователей в группы. Группы ролевого управления доступом аналогичны группам службы каталогов Active Directory®, но они существуют для определенного набора приложений, одного приложения или области внутри приложения.

Authorization Manager поддерживает два типа групп областей приложения:

  • Базовая группа приложения. Как и группы Windows NT, базовая группа приложения содержит список членов. В отличие от групп Windows NT в ней существует дополнительный список тех, кто не является ее членами. Такой список позволяет указывать исключения, т. е. в большой группе исключается меньшая группа или пользователь.
  • Группа запроса Lightweight Directory Access Protocol. Группа, определенная запросом Lightweight Directory Access Protocol (LDAP) к атрибутам учетной записи пользователя в данной службе каталогов Active Directory. При обращении к ресурсу выполняется LDAP-запрос и определяется, является ли пользователь членом данной группы. Это допускает гибкое членство в группах, соответствующее текущему состоянию объекта учетной записи пользователя в Active Directory. Например, группа Managers может содержать LDAP-запрос, перечисляющих всех пользователей, у которых есть отчеты.
    Простота Authorization Manager проистекает из его реализации ролевого управления доступом. Администраторы авторизации разрабатывают роли в виде набора заданий, поддерживаемых приложением, а затем назначают роли пользователям и группам, чтобы те могли выполнять эти задания. Разработчики приложений используют защищенные логические объекты, имеющие смысл как в контексте приложения, так и в контексте модели управления безопасностью, облегчая и разработку приложения, и администрирование.

Хранилище, используемое при авторизации

Инфраструктура авторизации, основанная на объектах, хранит список прав доступа в DACLS объектов. Однако в ролевой модели сведения о защите хранятся отдельно от объектов в хранилище политик.

При инициализации приложение, использующее Authorization Manager, загружает сведения о политике авторизации из хранилища. Authorization Manager в Windows Server 2003 позволяет хранить политику авторизации либо в Active Directory, либо в XML-файлах. Администраторы системы, содержащей такое хранилище, имеют высокий уровень доступа к хранилищу, поэтому хранилище политик авторизации следует размещать в доверяемой системе.

При использовании хранилища Active Directory Authorization Manager создает объекты Active Directory для самого хранилища и дочерние объекты для каждой группы приложений, приложения, задания, роли и области. Объект "область" может содержать задания, роли и группы, созданные в этой области.

Кроме того, Authorization Manager позволяет хранить политику авторизации в XML-файле в файловой системе NTFS (защищенном ACL-списком). XML-хранилище может располагаться на том же компьютере, что и сервер Authorization Manager, или на удаленном компьютере. Для поддержки переименования объектов формат XML содержит глобально уникальные идентификаторы (globally unique identifiers, GUID), поэтому редактирование XML-файла напрямую - задача нетривиальная, и она не поддерживается. Для редактирования хранилища применяются пользовательский интерфейс Authorization Manager MMC или COM-интерфейсы, предоставляемые Authorization Manager в сценарных языках типа VBScript и Jscript®.

Процесс разработки приложения, использующего Authorization Manager

Включение управления доступом на основе ролей в приложение осуществляется самым обычным образом.

  • Во время разработки приложения определите роли, реализуйте операции и объедините операции в задания.
  • При установке приложения вызовите соответствующие API-функции для создания хранилища политик авторизации, создайте операции и задания (и, возможно, начальные роли, требуемые приложению).
  • При выполнении приложение инициализирует Authorization Manager, последний соединяется с хранилищем и устанавливает соединение с разделом в хранилище, относящимся к приложению.
  • Когда клиент соединяется с приложением, последнее создает контекст авторизации клиента.
  • Реализуйте разное поведение в зависимости от ролей. Теперь вы можете получать роли этого пользователя и изменять интерфейс в соответствии с ними (например, "менеджер" может видеть не то же самое, что "консультант"). При выполнении операции вызывается AccessCheck. Роли, к которым принадлежит пользователь, перечисляются; каждое задание для каждой роли проверяется, чтобы выяснить, можно ли выполнить запрошенную операцию.

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

Рис. 3. Пример управления доступом на основе ролей: менеджер

Рис. 4. Пример управления доступом на основе ролей: пользователь

Определение ролей и заданий

В предыдущем приложении-примере две роли: Expense User, который может отправлять отчеты о расходах, и Manager, отправляющий и утверждающий отчеты. Роли Expense User назначена группа Active Directory "Everyone". Роль Manager состоит из LDAP-группы "Managers". Группа Managers определена следующим LDAP-запросом:

(title=Manager)

В нашем приложении-примере две операции: "submit" ("отправить") и "approve" ("утвердить"). Также создано два задания: "Submit Expense", состоящее из операции "submit", и "Approve Expense", соответствующее операции "approve".

Установка

Authorization Manager предоставляет COM-интерфейс, который разработчики могут использовать во время установки, создавая хранилище политик авторизации и все важные для выполнения приложения роли, задания и операции. Для установки приложения-примера можно воспользоваться следующим VBScript, выполняемом в Windows Scripting Host.

´--- Инициализация управляющего объекта
Dim pAzManStore
Set pAzManStore = CreateObject("AzRoles.AzAuthorizationStore")

´--- Создать новое хранилище для приложения-отчета о расходах
´ AZ_AZSTORE_FLAG_CREATE   = 0x1,
´ AZ_AZSTORE_FLAG_MANAGE_STORE_ONLY   = 0x2,
´ AZ_AZSTORE_FLAG_BATCH_UPDATE   = 0x4,

´--- Создать новое XML-хранилище для приложения, генерирующего
´ отчеты о расходах
pAzManStore.Initialize 1+2, "msxml://C:\JetAzStore.xml"

´--- Создать новое AD-хранилище для того же приложения
´pAzManStore.Initialize 1+2, "msldap://CN=MyWebAppsAzStore,CN=Program Data,DC=azroles,DC=com"

pAzManStore.Submit

Dim App1
Set App1 = pAzManStore.CreateApplication("JetExpense")
App1.Submit


´--- Создать операции -----------------------

Dim Op1
Set Op1=App1.CreateOperation("Submit")
Op1.OperationID = CLng(55)
Op1.Submit

Dim Op2
Set Op2=App1.CreateOperation("Approve")
Op2.OperationID = CLng(56)
Op2.Submit


´--- Создать задания ------------------------------

Dim Task2
Set Task2 = App1.CreateTask("Submit Expense")
Task2.BizRuleLanguage = CStr("VBScript")
Task2.AddOperation CStr("Submit")
Task2.BizRule = "Dim Amount" & vbnewline  & _
                "AzBizRuleContext.BusinessRuleResult = FALSE" & vbnewline & _
                "Amount = AzBizRuleContext.GetParameter( " & Chr(34) & _
                              "ExpAmount" & Chr(34) & ")"  & vbNewLine & _
                "If Amount < 500 Then AzBizRuleContext.BusinessRuleResult = TRUE"

Task2.Submit

Set Task2 = App1.CreateTask("Approve Expense")
Task2.BizRuleLanguage = CStr("VBScript")
Task2.AddOperation CStr("Approve")
Task2.BizRuleImportedPath = "C:\Approve.vbs"

Task2.Submit

´--- Создать определения ролей ------------------------------
Set Task3 = App1.CreateTask("Expense User")
Task3.AddTask CStr("Submit Expense")
Task3.IsRoleDefinition = TRUE
Task3.Submit

Set Task3 = App1.CreateTask("Manager")
Task3.AddTask CStr("Submit Expense")
Task3.AddTask CStr("Approve Expense")
Task3.IsRoleDefinition = TRUE
Task3.Submit

´--- Создать начальные области и роли ------------------------------
´--- В приложении всего одна область (можно было бы вообще
´ отказаться от областей)

Set RoleA=App1.CreateRole("Expense User")
RoleA.AddTask("Expense User")
RoleA.Submit

Set RoleB=App1.CreateRole("Manager")
RoleB.AddTask("Expense User")
RoleB.AddTask("Manager")
RoleB.Submit

´--- Создать группу приложения --------------------------

Set Group1 = App1.CreateApplicationGroup("Managers")
Group1.Type = 1
Group1.LdapQuery = "(title=Manager)"
Group1.Submit


´--- Demo - добавить всех в роль Expense User --------------------------
RoleA.AddMember("S-1-1-0")
RoleA.Submit

´--- Demo - добавить менеджеров в роль Manager --------------------------
RoleB.AddAppMember("Managers")
RoleB.Submit

Инициализация Authorization Manager и доступ к хранилищу

Authorization Manager предоставляет COM-интерфейс. ProgID основного объекта - хранилища политик авторизации - Azroles.AzAuthorizationStore. Приложение должно создать объект AzAuthorizationStore и инициализировать его, указав на требуемое хранилище.

´--------------- Создать объект хранилища политик авторизации --------------
Set AzManStore = CreateObject("Azroles.AzAuthorizationStore")

´--------------- Загрузить требуемое хранилище --------------
AzManStore.Initialize 0, "msxml://C:\JetAzStore.xml"

Политика авторизации может существовать в хранилище на глобальном уровне (т. е. определения доступны всем приложениям, указанным в нем) или привязываться к конкретным приложениям. То есть менеджер в одном приложении может иметь совершенно другие полномочия в другом. Объект хранилища может открывать конкретные приложения.

´--------------- Открыть приложение --------------
Set App = AzManStore.OpenApplication ("JetExpense")

Инициализация клиентского контекста при соединении с клиентом

Затем приложение должно инициализировать клиентский контекст для связывания пользователя с его ролью.

´--------------- Создать контекст клиента --------------
Set CCHandle = App.InitializeClientContextFromToken(0, 0)

Реализация различного поведения в зависимости от роли

После создания клиентского контекста приложение может запрашивать информацию о роли пользователя, чтобы сформировать соответствующий пользовательский интерфейс. В нашем примере часть интерфейса Approve Expense видна только членам роли Manager. Метод IAzClientContext::GetRoles перечисляет членство пользователя в ролях.

´--------------- Выяснить роль пользователя --------------
Manager = False
Roles = CCHandle.GetRoles()
For each Role in Roles
   Response.Write Role
    If ( StrComp( Role, "Manager", 1 ) = 0 ) Then
      Manager = True
   End If 
Next

Set CCHandle = Nothing
set App = Nothing
Set AzManStore = Nothing

Когда клиент делает запрос или какие-то события заставляют приложение выполнить некое задание, приложение должно вначале определить, разрешено ли выполнение такого задания. Для этого оно вызывает IAzClientContext::AccessCheck. AccessCheck возвращает нуль, если доступ авторизован.

Names(0) = "ExpAmount"
Values(0) = 0
Names(1) = "Param2 for BizRule - Name"
Values(1) = "Param2 for BizRule - value"
Scopes(0) = Empty
Operations(0) = 55

´-------- AccessCheck -----------------------------------------
´ Проверить, разрешено ли текущему пользователю отправить отчет,
´ передав параметры AccessCheck (в нашем случае - только сумму расходов
´ и выполняемую операцию)

Results = CCHandle.AccessCheck("Submit Expense", Scopes, Operations, Names, Values)
     
If Results(0) = 0 Then ´ Zero = NO_ERROR
   Result = "accepted."
Else
   Result = "denied."
End If

Заключение

Управление доступом на основе ролей, поддерживаемое в Windows Server 2003 (Enterprise Server) предоставляет облегченную модель разработки для бизнес-приложений определенных типов. Администраторы и разработчики выигрывают от использования естественной среды, позволяющей им эффективно моделировать как организационную структуру, так и бизнес-процессы.


Может пригодится:


Автор: Моэн Рао Кавейл, Microsoft Corporation
Прочитано: 8301
Рейтинг:
Оценить: 1 2 3 4 5

Комментарии: (0)

Добавить комментарий
Ваше имя*:
Ваш email:
URL Вашего сайта:
Ваш комментарий*:
Код безопастности*:

Рассылка новостей
Рейтинги
© 2007, Программирование Исходники.Ру