Использование встроенного механизма авторизации в составе Windows 2003 на платформе Windows 2000 Server Текст научной статьи по специальности «Компьютерные и информационные науки»

менее, использования данных подобного средства в большинстве проектов оказывается недостаточно, и разработчикам приходится реализовывать дополнительную логику контроля качества данных на этапе ЕТЬ.

В заключение отметим, что мы рассмотрели понятие хранилища данных, а также задачи, решение которых определяет успех проекта по созданию хранилища данных:

- предоставление инструмента анализа информации;

- проектирование хранилища с использованием многомерной модели данных;

- разработка процедур ETL;

- обеспечение приемлемого качества данных.

Список литературы

1. Kimball R., Caserta J. The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Confirming and Delivering Data. Wiley, 2004. 525 p.

2. Kimball R., Ross M. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. Wiley, 2002. 421 p.

3. Nissen G. Is Hand-Coded ETL the Way to Go? // Intelligent Enterprise Magazine. 2003. Vol. 6. № 9 [HTML] (http://www.iemagazine.com /030531/609warehouse1_1 .jhtml).

4. Olson J. Data Quality Accuracy Dimension. Morgan Kauffmann Publishers, 2003. 293 p.

ИСПОЛЬЗОВАНИЕ ВСТРОЕННОГО МЕХАНИЗМА АВТОРИЗАЦИИ В СОСТАВЕ WINDOWS 2003 НА ПЛАТФОРМЕ WINDOWS 2000 SERVER

Г.Б. Ситков, А.А. Усов, В.И. Наумов

С момента появления надстройки Authorization Manager в составе Windows 2003 многие разработчики, и мы в том числе, стали активно использовать это средство для разграничения доступа на основе ролей (RBAC). Среди преимуществ Authorization Manager достаточно упомянуть хорошую реализацию настроечной части (интерфейс в MMC) и, как следствие, возможность полностью возложить задачу поддержки конфигурации подсистемы авторизации на плечи ИТ - отдела заказчика. Достаточно поставлять настроенную в соответствии с бизнес-логикой заказчика структуру RBAC. А изменение пользователей системы и распределение их по ролям - непрерывный процесс в активно развивающихся современных компаниях.

Однако не всегда на площадке заказчика установлены Windows 2003 или Windows XP. Многие довольствуются приобретенными ранее сетями под управлением контроллеров доменов на основе Windows 2000 Server. К сожалению, под эту операционную систему Microsoft предоставляет только набор run time-библиотек (COM+) для работы с компонентами Authorization Manager.

С подобным положением вещей авторам пришлось столкнуться при разработке корпоративного web-приложения для заказчика. Нами была написана простая вспомогательная утилита для добавления, редактирования и удаления членов Application Group в Authorization Manager.

Реализация системы безопасности

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

• мультидоменное сетевое окружение с доверительными отношениями между доменами;

• требование удаленного доступа к настройкам конфигурации программного обеспечения, в том числе к настройкам подсистемы безопасности;

• работа контроллеров домена под управлением Windows 2000 Server;

• использование встроенной поддержки безопасности Windows;

• отсутствие Active Directory и LDAP (все настройки Authorization Manager хранятся в xml-файле).

Авторизация доступа в ИС была собрана в одном Application в Authorization Manager. Соответственно для этого Application и настраивались члены локальной Application Group при помощи описываемой утилиты.

Организация приложения и работы с интерфейсами AzMan

Утилита представляет собой ASP.NET web-приложение, написанное на C#. Приложение состоит из двух экранных форм: первая - для выбора Application Group и отображения членов, входящих в ее состав; вторая вызывается модально и служит для выбора группы домена(ов), которые будут добавлены в Application Group.

Интерфейсы для работы с Authorization Manager достаточно хорошо документированы в MSDN, поэтому не будем останавливаться на их рассмотрении. Для изучения принципов RBAC в понимании Microsoft рекомендуем разработчикам ознакомиться со списком литературы, приведенным в конце статьи.

Необходимая сборка для работы с Authorization Manager называется Microsoft.Interop.Secu-rity.AzRoles. В зависимости от операционной системы и установленных сервис-паков эта сборка может присутствовать или отсутствовать на компьютере в Global Assembly Cash. Если ее нет, то можно использовать tlbimp для генерации сборки из библиотеки AzRoles.dll из каталога system32 операционной системы.

Настройки утилиты хранятся в файле web.config. Основные из них: <appSettings>

<add key="PolicyStorageType" value="msxml://"/> <add key="PolicyStoragePath" value="C:\SecurityFolder\"/> <add key="PolicyStorageName" value="Security.xml"/> <add key="ApplicationName" value="MyApplication"/> <!-- DomainName: must be empty for local groups --> <add key="DomainName" value=""/> </appSettings>

PolicyStorageType - тип хранилища Authorization Manager (xml или ldap);

PolicyStoragePath - каталог, в котором хранится xml-файл;

PolicyStorageName - имя xml-файла с настройками RBAC;

ApplicationName - имя приложения, группы которого будут настраиваться;

DomainName - имя домена, члены которого могут входить в состав групп Authorization Manager для ИС.

Для удобства работы авторами был написан класс-надстройка, аккумулирующий в себе функции выборки, редактирования и удаления членов Application Groups в Authorization Manager.

Рассмотрим реализацию описанного выше класса-надстройки.

Объявление класса:

public class AzManCommon {

}

Интерфейс к хранилищу RBAC выделен в отдельное свойство: private AzAuthorizationStoreClass m_Storage;

Конструктор класса AzManCommon:

/// <summary> /// Конструктор /// </summary>

/// <param name="bstrPolicyURL">Путь к файлу или каталогу с policy</param>

public AzManCommon(String bstrPolicyURL) {

m_Storage = new AzAuthorizationStoreClass(); if (m_Storage == null)

throw new AzManException("Ошибка при попытке доступа к хранилищу RBAC.");

// Инициализируем хранилище для редактирования m_Storage.Initialize(0, bstrPolicyURL, null);

}

Методы класса AzManCommon для обработки операций выборки, добавления и удаления в Application Groups: /// <summary>

/// Возвращает список Application Groups для указанного /// приложения. /// </summary>

/// <param name="szAppName">Имя приложения</param> /// <шШг^>Список имен Application Groups</returns>

public String[] get_ApplicationGroups(String szAppName) {

if (m_Storage == null)

throw new AzManException("Не проинициализиро-вано хранилище RBAC.");

String[] lpszAppGroups = null;

for (int i = 1; i < m_Storage.Applications.Count + 1; i++) {

IAzApplication iunkApplication = (IAzApplica-tion)m_Storage.Applications[i];

if (iunkApplication.Name == szAppName) {

lpszAppGroups = new String[iunkApplication. Appli-cationGroups.Count];

for (int j = 1; j < iunkApplication.Applica-

tionGroups.Count + 1; j++) {

IAzApplicationGroup iunkAppGroup =

(IAzApplicationGroup)iunkApplication.Appli-

cationGroups[j];

lpszAppGroups[j - 1] = iunkAppGroup.

Name;

}

break;

}

}

return lpszAppGroups;

}

/// <summary>

/// Возвращает список членов Application Group /// </summary>

/// <param name="szAppName">Имя приложения</param> /// <param name="szAppGrpName">Имя Application Group</param>

/// <шШг^>Список структур с именами и SID для каждого члена</геШ1:ш>

public structMemberDescr[] get_ApplicationGroupMem-

bers(String szAppName, String szAppGrpName) {

if (m_Storage == null)

throw new AzManExceptionC^ проинициализиро-вано хранилище RBAC.");

structMemberDescr[] lpstructAppGroupMembers = null;

for (int i = 1; i < m_Storage.Applications.Count + 1; i++) {

IAzApplication iunkApplication = (IAzApplica-tion)m_Storage.Applications [i];

if (iunkApplication.Name == szAppName) {

for (int j = 1; j < iunkApplication.Applica-

tionGroups.Count + 1; j++) {

IAzApplicationGroup iunkAppGroup = (IAzApplicationGroup)iunkApplication.Application

Groups[j];

if (iunkAppGroup.Name == szAppGrp Name) {

System.Array memberArray = (System. Array)iunkAppGroup.MembersName;

lpstructAppGroupMembers = new struct MemberDescr[memberArray.GetLength(0)];

for (int n = 0; n < memberArray.Length;

n++)

lpstructAppGroupMembers [n]. szMemberName = Convert.ToString(memberArray.GetValue(n));

System.Array memberSIDArray = (Sys-tem.Array)iunkAppGroup.Members;

for (int n = 0; n < memberSIDArray.

Length; n++)

lpstructAppGroup-Members[n].szMemberSID = Convert.ToString(memberSIDArray. GetValue(n));

break;

}

}

}

}

return lpstructAppGroupMembers;

}

/// <summary>

/// Добавляет члена в группу /// </summary>

/// <param name="szAppName">Имя приложения</param> /// <param name="szAppGrpName">Имя Application Group</param>

/// <param name="szMemberSID">SID члена</param> public void add_ApplicationGroupMember(String szApp

Name, String szAppGrpName, String szMemberSID) {

if (m_Storage == null)

throw new AzManException("Не проинициали-зировано хранилище RBAC.");

if (szMemberSID.Length == 0)

throw new AzManExceptionC^ указан SID группы.");

for (int i = 1; i < m_Storage.Applications.Count + 1; i++) {

IAzApplication iunkApplication = (IAzApplica-tion)m_Storage.Applications[i];

if (iunkApplication.Name == szAppName) {

for (int j = 1; j < iunkApplication.Applica-

tionGroups.Count + 1; j++) {

IAzApplicationGroup iunkAppGroup = (IAzApplicationGroup)iunkApplication. ApplicationGroups[j];

if (iunkAppGroup.Name == szAppGrp Name) {

iunkAppGroup.AddMember(szMemberSID,

null);

iunkAppGroup.Submit(0, null); break;

}

}

}

}

}

/// <summary>

/// Удаляет члена из группы

/// </summary>

/// <param name="szAppName">Имя приложения</param>

/// <param пате="82АррвгрМаше">Имя Application Group</param>

/// <param name="szMemberSID">SID члена</param> public void del_ApplicationGroupMember(String szAppName,

String szAppGrpName, String szMemberSID) {

if (m_Storage == null)

throw new AzManExceptionC^ проинициализиро-вано хранилище RBAC.");

if (szMemberSID.Length == 0)

throw new AzManExceptionC^ указан SID группы.");

for (int i = 1; i < m_Storage.Applications.Count + 1; i++) {

IAzApplication iunkApplication = (IAzAppli-cation)m_Storage.Applications[i];

if (iunkApplication.Name == szAppName) {

for (int j = 1; j < iunkApplication.Applica-

tionGroups.Count + 1; j++) {

IAzApplicationGroup iunkAppGroup = (IAzApplicationGroup)iunkApplication.Appli-

cationGroups[j];

if (iunkAppGroup.Name == szAppGrp Name)

{

iunkAppGroup.DeleteMember(szMemberSID,

null);

iunkAppGroup.Submit(0, null); break;

}

}

}

}

}

В приведенной реализации используются два вспомогательных класса: AzManException - для обработки исключений, возникших при операциях с Authorization Manager, и структура structMem-berDescr - для передачи списков между классом-надстройкой AzManCommon и интерфейсной частью.

Для получения списка групп домена использованы возможности системы Windows Management Instrumentation (WMI). Приведем исходный код обращения к WMI и формирование запроса. protected System.Web.UI.WebControls.DropDownList ddGroup;

ManagementScope msc = new ManagementScope ("root\\cimv2");

string queryString = "SELECT Domain, Name, SID FROM Win32_Group";

string szDomainName = ConfigurationSettings.AppSettings ["DomainName"];

if (szDomainName.Length != 0)

queryString += " WHERE Domain=\" " + szDomainName +

SelectQuery q = new SelectQuery(queryString); ManagementObjectSearcher query = new Management ObjectSearcher(msc, q);

ManagementObjectCollection queryCollection = query.Get();

ddGroup.Items .Clear();

ddGroup.Items.Add("");

foreach( ManagementObject mo in queryCollection ) {

ddGroup.Items.Add(new ListItem(mo["Name"]. To

String(), mo["SID"].ToString())); }

Обращение к методам класса AzManCommon из интерфейсной части можно посмотреть

в прилагаемых к этой статье исходных кодах утилиты.

Дополнительные возможности

Немного изменив код, можно добавлять, редактировать и удалять членов общей Application Group хранилища RBAC. Также, немного изменив алгоритм работы с WMI, применяемый в утилите, можно настраивать не только доменные группы в составе Application Group, но и отдельно добавлять членов этих групп.

Список литературы

1. MSDN. Platform SDK: Authorization. Authorization Manager Model: http://msdn.microsoft.com/library/default. asp?url=/library/en-us/secauthz/security/authorization_manager_ model.asp

2. MSDN. Role-Based Access Control Using Windows Server 2003 Authorization Manager. Mohan Rao Cavale. Microsoft Corporation. January 2003: http://msdn.microsoft.com/libra-ry/default.asp?url=/library/en-us/dnnetserv/html/AzManRoles.asp

3. MSDN Magazine November 2003. Use Role-Based Security in Your Middle Tier .NET Apps with Authorization Manager. Keith Brown. http://msdn.microsoft.com/msdn-mag/issues/03/11/AuthorizationManager/

ФОРМИРОВАНИЕ КОНЦЕПТУАЛЬНЫХ ПРОЕКТНЫХ РЕШЕНИЙ НА КЛАССИФИКАЦИОННЫХ СТРУКТУРАХ

Г.П. Лазаренко

Проектирование как один из широко распространенных видов интеллектуальной деятельности характеризуется устойчивым жизненным циклом, структура которого зафиксирована в международных стандартах [1, 2]. Согласно этим стандартам, первой и одной из наиболее ответственных стадий жизненного цикла является формирование концепции проекта, которая обычно формулируется в виде вербальных высказываний, задающих главную идею проекта на уровне понятий. В сложившейся проектной практике [3] концепция формируется в высшем управленческом звене проекта, причем для этого обычно используется эвристический метод, основывающийся на личных профессиональных знаниях авторов концепции. Очевидно, что такой, в значительной степени субъективный подход не гарантирует оптимальности принимаемых решений и не может считаться надежным проектным инструментом. Альтернативой эвристическому методу должна служить методология, которая опирается на тщательно подготовленную, широко обобщенную и четко структурированную информацию, всесторонне описывающую проектируемую сущность, а также на формализованную логику обработки этой информации. Один из вариантов реализации такой методологии обсуждается в настоящей работе.

Формирование концептуальных проектов включает две фазы - генерирование альтернативных концепций и выбор предпочтительной альтернативы.

Генерирование концепций строится на анализе существующей понятийной информации о рассматриваемой сущности. Структурированное понятийное описание сущности может существовать в различных формах, среди которых важное место занимают фасетные классификаторы [4], кото-

рые представляют данные о рассматриваемой сущности в виде системы соподчиненных атрибутов этой сущности.

Фасетные классификаторы относятся к группе классификаторов комбинаторного типа. В простейшем варианте фасетный классификатор представляет собой связный двухуровневый древовидный граф, вершины которого задают состав атрибутов, описывающих классифицируемую сущность, а ребра - структуру отношений между этими атрибутами. Нулевым уровнем фасетного классификатора является вершина, задающая классифицируемую сущность. Вершины первого уровня выполняют роль дискриминаторов и описывают аспекты классификации. Второй уровень классификатора образован вершинами графа, которые содержат атрибуты-категории (далее - атрибуты), представляющие собой наборы альтернативных реализаций дискриминаторов. В общем случае такая фасетная классификационная структура содержит I дискриминаторов, которые декомпозированы на группы, включающие по Л атрибутов.

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

Например, для генерирования концепций сущности «Металлорежущий станок» можно воспользоваться фасетным классификатором (см.