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

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

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

Применение динамических бизнес-правил в Windows Server 2003 Authorization Manager
Обзор поддержки динамических бизнес-правил в новом интерфейсе управления доступом, Authorization Manager, введенном в Windows Server 2003.

Аннотация

Обзор поддержки динамических бизнес-правил в новом интерфейсе управления доступом, Authorization Manager, введенном в Windows Server 2003.

Содержание

Введение
Объектно-ориентированное управление доступом
Управление доступом на основе ролей в Authorization Manager
Элементы BizRule
Добавление элементов BizRule в ваше приложение
Заключение

Введение

В системах, предшествующих Windows Server 2003, модель авторизации была объектно-ориентированной. В таких системах управление осуществлялось через списки управления доступом (access control lists, ACL); каждому объекту соответствовал список доверяемых объектов (учетных записей пользователей, групповых учетных записей или сеансов регистрации), для каждого объекта устанавливался собственный набор полномочий. Такое управление доступом отлично работает для некоторых типов приложений. Наборы ресурсов, содержащие четко определенные, постоянные объекты, например реестр Windows NT®, хорошо работают с ACL. ACL можно связать с объектом, и тогда решение о предоставлении доступа принимается на основе группового членства и содержимого ACL. В таких приложениях практически не нужна бизнес-логика вроде времени суток или других переменных периода выполнения, учитываемых при принятии решения о доступе.

Другая дело - бизнес-приложения в Web, например приложение для отчетности о расходах или электронный магазин. В такого рода приложениях решение об авторизации зачастую не определяет доступ к четко определенным, постоянным объектам, а контролирует процесс или набор различных операций, скажем, запросы к базе данных и отправку электронной почты. Такие решения часто принимаются не только на основе маркера членства в группе, но и бизнес-логики, например суммы, введенной в отчет о расходах, или проверки завершения процесса. Приложениям, не содержащим четко определенных, постоянных объектов, не с чем связать ACL. В Windows Server 2003 компонент Authorization Manager предоставляет динамические бизнес-правила ("BizRule") для принятия динамических решений о доступе.

Объектно-ориентированное управление доступом

Рис. 1. Пользовательские разрешения на доступп

{
Надписи на рисунке:
Bob - Боб
Mary - Мэри
Chris - Крис
Permissions managed and checked at backend via ACLs - Проверка и управление разрешениями выполняется на сервере через ACL
}

Когда приложение получает запрос от клиента на ресурс, защищаемый RM, последний подменяет клиент и вызывает API-функцию AccessCheck. В свою очередь AccessCheck анализирует маркер защиты клиента, запрошенный уровень доступа к объекту и дескриптор его защиты. AccessCheck отвечает RM "да" или "нет", позволяя последнему принять решение о запрете или разрешении доступа. Атрибуты дескриптора защиты объекта и маркер защиты клиента устанавливаются до запроса. Например, администратор задал определенные полномочия на доступ к файлу. В этой модели нельзя динамически влиять на результаты проверки доступа на основе внешних факторов вроде времени суток или запрошенной суммы в долларах.

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

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

В Windows Server 2003 введен новый интерфейс управления доступом, основанный на ролях, - Authorization Manager. Его цели таковы:

  • облегчить управление доступом в приложении;
  • предоставить более простую и естественную модель разработки;
  • обеспечить поддержку гибких и динамичных решений об авторизации.

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

Рис. 2. Полномочия пользователей в Authorization Manager

{
Надписи на рисунке:
Authorization Store - Хранилище политик авторизации
Role within application - Роль в приложении
Bob - Боб
Mary - Мэри
Chris - Крис
Permissions managed and checked at application server in authorization store - Проверка и управление разрешениями выполняется на сервере приложений в хранилище политик авторизации
}

В такой системе логические роли и задания определяются и поддерживаются в соответствии с нуждами каждого приложения. Представление модели безопасности в соответствии с организационной структурой облегчает управление доступом. Кроме того, определение ролей и заданий способствуют моделированию рабочих процессов приложения, создавая для разработчиков естественную, ориентированную на приложение среду при использовании Authorization Manager.

Кроме того, Authorization Manager позволяет динамически модифицировать выданные разрешения в период выполнения. Это позволяет принимать во внимание при решении о предоставлении доступа данные периода выполнения, например запрошенную сумму в долларах или наличие запрошенного товара. Для обеспечения такой функциональности с заданием связывается BizRule (процедура на VBScript или Jscript®). BizRule выполняется при проверке разрешений во время работы приложения. Если BizRule выполнен успешно, пользователь получает результат запрошенных операций, связанных с заданием, а иначе операции, связанные с заданием, не выполняются.

Компоненты приложения Authorization Manager

Приложение Authorization Manager состоит из (или использует) следующие объекты.

  • Хранилище политик авторизации: набор определений ролей, назначений ролей пользователям и группам, определений заданий и операций.
  • Задания: набор операций (или других заданий), требуемых для выполнения какой-то работы, имеющей значение для администраторов.
  • Области (scopes): набор заданий или ресурсов с различными политиками авторизации, т. е. у всех заданий и ресурсов в области одни и те же требования к доступу.
  • Роли: набор разрешений, необходимых пользователю для его работы. Роль применяется к набору объектов и имеет семантику для пользователей, которым она назначена.
  • Базовые и динамические группы: списки пользователей или групп службы каталогов Active Directory или иные группы Application Group с дополнительным списком тех, кто не является членом этих групп. Базовые группы - это статические списки. Состав динамических групп определяется во время выполнения через LDAP-запросы атрибутов учетной записи клиента в Active Directory.
  • BizRule (или сценарии авторизации): сценарии, связанные с объектами задания. С одним объектом нельзя связать более чем один сценарий BizRule, выполняемый при запросе на доступ к заданию. BizRule принимает решение об авторизации на основе информации, доступной только в период выполнения, например с учетом времени суток или запрошенной суммы в долларах.
    Проектирование приложения требует тщательного определения ролей, заданий и областей внутри приложения. Администраторы авторизации создают роли в виде набора заданий, поддерживаемых приложением, и назначают их пользователям и группам, выдавая последним права на выполнение этих заданий. Для заданий, права на выполнение которых определяются в период работы приложения, создаются BizRule.

Элементы BizRule

BizRule - это сценарий (на VBScript или JScript), связанный с заданием. При поступлении запроса на доступ к заданию, с которым связан BizRule, запускается Window Scripting Engine для выполнения последнего. Так как выполнение каждого BizRule требует запуска Windows Script Engine, BizRule должен быть небольшого объема. Распространенный пример - сравнение переданных параметров или выдача запроса к базе данных.

Приведенный ниже образец BizRule на JScript демонстрирует, как предоставлять доступ в зависимости от времени суток; в данном случае BizRule возвращает true, если вызывается между девятью утра и пяти вечера:

AzBizRuleContext.BusinessRuleResult = false;
dt = new Date(); 
hour = dt.getHours();

if (hour > 9 && hour < 17)
{
   AzBizRuleContext.BusinessRuleResult = true;
}

Для большей производительности часто вызываемых BizRule его результат кэшируется на срок жизни клиентского контекста. Следовательно, если BizRule лишь проверяет время (как в предыдущем примере), приложение кэширует контекст клиента на крайне непродолжительное время.

Следующий BizRule на VBScript проверяет, передано ли ему число, большее 25:

Dim Amount
AzBizRuleContext.BusinessRuleResult = FALSE
Amount = AzBizRuleContext.GetParameter("Age")
if Amount > 25 then AzBizRuleContext.BusinessRuleResult = TRUE

AzBizRuleContext.BusinessRuleResult = False
Dim Amount

Amount = AzBizRuleContext.GetParameter("ExpAmount")

´ Не утверждать расходы по четвергам. В другие дни утверждать
´ расходы только на сумму не более $500.
If ( Not ( Weekday( Now ) = 4 ) ) Then
   If ( Amount < 500 ) Then AzBizRuleContext.BusinessRuleResult = True
End If

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

AzBizRuleContext

Объект AzBizRuleContext предназначен для взаимодействия между приложением и BizRule. Он создается автоматически и доступен всем сценариям BizRule. Этот объект содержит два свойства: BusinessRuleResult и BusinessRuleString. BusinessRuleResult используется, чтобы указывать, разрешено ли пользователю выполнять запрошенное задание. Сценарий возвращает true, если разрешение есть, и false в ином случае.

Первым делом в сценарии BizRule следует немедленно записать FALSE в BusinessRuleResult, если доступ следует запрещать в случае неизвестных ошибок. A

zBizRuleContext.BusinessRuleResult = False

Иначе, если BizRule прекратит досрочно выполнение из-за ошибки в коде или проблемы в среде, случайные данные в BusinessRuleResult могут трактоваться как TRUE, а это приведет к тому, что доступ будет предоставлен.

Свойство BusinessRuleString применяется для установки или получения специфичной для приложения строки в BizRule. Ее формат и содержимое определяется приложением. Одно ее из возможных применений - объяснение причины, по которой BizRule отказал пользователю в доступе.

AzBizRuleContext содержит единственный метод GetParameter, используемый для получения значений, переданных BizRule из приложения. Метод принимает один аргумент - имя получаемого параметра.

Amount = AzBizRuleContext.GetParameter("ExpAmount")
Service = AzBizRuleContext.GetParameter("YearsOfService")

В Authorization Manager версии 1.0 поддерживаются только VBScript и Jscript. В этих сценариях нельзя использовать управляемые объекты. BizRule следует тщательно тестировать, прежде чем поместить в задание. Зачастую разработчикам приложений очень трудно обнаружить и диагностировать причины ошибок пеирода выполнения в сценариях.

Добавление элементов BizRule в ваше приложение

Существуют общие правила встраивания BizRule в приложение:

  • на этапе разработки приложения вы создаете BizRule с помощью MMC-оснастки AzMan;
  • в период выполнения приложение инициализирует Authorization Manager, который соединяется с хранилищем политик авторизации, а затем устанавливает соединение со специфичным для приложения разделом хранилища;
  • когда клиент соединяется с приложением, оно создает клиентский контекст авторизации;
  • с помощью API-функции AccessCheck вызываются BizRule, определяющие привилегии подключенного клиента;
  • при установке приложение вызывает требуемые API-функции для создания хранилища, операций и заданий (и, возможно, некоторых начальных ролей, требуемых приложению).

Создание или редактирование BizRule с помощью AzMan

Администратор приложения может добавлять или изменять BizRule в приложении после его развертывания. Для этого применяется MMC-оснастка Authorization Manager (AzMan.msc).

Для добавления или редактирования BizRule запустите оснастку AzMan и откройте хранилище Authorization Store. Раскройте подходящие приложения до Definitions, Task Definitions; щелкните правой кнопкой мыши требуемое задание в правом окне и выберите Properties. Затем откройте вкладку Definition и щелкните Authorization Script.

 

Появится диалоговое окно Authorization Rule, показанное на рисунке ниже.

Рис. 3. Диалоговое окно Authorization Script

Чтобы создать новый BizRule, создайте файл с требуемым сценарием и загрузите его, щелкнув Reload Rule into Store. После каждого изменения файла, содержащего BizRule, его нужно загрузить заново, чтобы изменения вступили в силу. Чтобы загруженные файлы сценариев действовали, они должны оставаться доступными по заданному пути.

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

Приложение, использующее BizRule, должно выполнить стандартную инициализацию Authorization Manager. Когда серверное приложение AM запущено, оно инициализирует экземпляр хранилища, вызывая IAzAuthorizationStore::Initialize. После инициализации хранилища приложение создает экземпляр интерфейса к данным приложения в хранилище, вызывая IAzAuthorizationStore::OpenApplication, а затем ожидает подключений клиентов.

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

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

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

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

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

  • IAzApplication::IntiializeClientContextFromToken;
  • IAzApplication::AzInitializeClientContextFromStringSid;
  • IAzApplication::InitializeClientContextFromName.
´--------------- Создать клиентский контекст --------------
Set CCHandle = App.InitializeClientContextFromToken(0, 0)

Вызов BizRule

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

В следующем примере серверного кода отчет о затратах отправляется на обработку только в том случае, если AccessCheck авторизует доступ к операции Submit (id=55). Сам вызов, выполняющий связанный код (DoSubmitExpense), исходит от приложения, а не от Authorization Manager (AccessCheck не выполняет задания, а просто возвращает данные о том, разрешено ли пользователю исполнять эту операцию).

  ´ Подготовить параметры, передаваемые AccessCheck
  Scopes(0) = Empty   ´ в случае Empty используется область действия
                      ´ приложения по умолчанию 
  Operations(0) = 55  ´ ID для операции Submit

  ´ Пары "Name-Value" AccessCheck передает BizRule, 
  ´ связанным с операциями в массиве Operations() (если они есть)

  Names(0) = "DayOfWeek"
  Values(0) = "Friday" 
  Names(1) = "ExpAmount"
  Values(1) = Clng( ValueFromUI )

  ´-------- AccessCheck -----------------------------------------
  ´ Выяснить, разрешено ли текущему пользователю отправлять отчет о затратах.

  Results = CCHandle.AccessCheck( "Submit Expense", _
                                  Scopes, _
                                  Operations, _
                                  Names, _
                                  Values )

  If Results(0) = 0 Then  ´ 0 - успешный ответ!
    DoSubmitExpense( ValueFromUI )
  Else
    ReportToClient( "Access Denied" )
  End If

В этом примере кода пары "имя-значение" передаются AccessCheck. Это делается для того, чтобы данные периода выполнения были доступны сценариям BizRule, связанным с элементами массива Operations(). Если с Operations() не связаны никакие BizRule, массивы Names() и Values() не используются и могут быть пустыми (просто опустить их нельзя, так как это обязательные параметры вызова AccessCheck).

Если в этом коде поменять местами первый и второй параметры - Names(0) и Names(1), сценарий не сработает. Массив Names (передаваемый AccessCheck) должен быть отсортирован в алфавитном порядке по возрастанию. В нашем случае имя "ExpAmount" должно идти после "DayOfWeek", так как в алфавитном порядке "DayOfWeek" меньше, чем "ExpAmount".

Создание BizRule в сценарии установки

Разработчики, желающие создавать BizRule при установке приложения, могут делать это программно. Authorization Manager содержит COM-интерфейс, позволяющий приложениям обращаться к хранилищу политик авторизации и создавать роли, задания и BizRule. Следующий код демонстрирует, как создать задание и связанный с ним BizRule.

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


Task1.Submit

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

Task2.Submit

Заключение

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


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


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

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

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

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