Рис. 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, предлагают гибкий и мощный механизм для динамического изменения и настройки пользовательских ролей в развернутом приложении. Кроме того, логику авторизации можно реализовать, не изменяя код приложения, что уменьшает вероятность нежелательных побочных эффектов при изменении процедур авторизации.