Интернет-журнал "Домашняя лаборатория", 2007 №6 - Усманов

сопровождалась подготовкой IDL файла с описаниями всех интерфейсов всех классов, включенных в приложение, то прокси каждого интерфейса (код которого сгенерирован Microsoft IDL), реализует интерфейс IClientSecurity. Таким образом, получив указатель на любой интерфейс некоторого объекта серверного приложения, клиентское приложение может (используя QueryInterfасе) получить указатель на IClientSecurity. Данный интерфейс имеет следующие методы:

• Query Blanket

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

• SetBlanket

Используется для задания нового уровня безопасности, который будет обеспечиваться для всех вызовов через данный прокси

• СоруРгоху

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

Еще один способ динамического задания уровня безопасности связан с заданием необходимого уровня безопасности при вызове функции построения нового серверного объекта. Напомним, что при вызове функции CoGetClassObject один из входных параметров является указателем на структуру COSERVERINFO. До настоящего момента мы полагали, что этот параметр равен NULL. В этом случае имя машины, где установлено серверное приложение, ищется в реестре машины клиента, а требования к уровню безопасности со стороны клиента определяются уровнем безопасности по умолчанию, заданным администратором локальной машины.

Желая использовать иные, чем по умолчанию, требования к уровню безопасности, клиентское приложение может вызвать функцию CoGetClassObject с указателем на структуру COSERVERINFO, содержащую, в частности, следующие данные:

• Используемый при работе с данным объектом сервис аутентификации (например, Kerberos)

• Сервис авторизации (NULL в случае Kerberos)

• Уровни аутентификации и имперсонализации

• Указатель на структуру с аутентификационными данными:

♦ Имя пользователя

♦ Пароль

♦ Домен

В результате, при построении нового серверного объекта клиентское приложение получит прокси настроенный на специфицированный в COSERVERINFO уровень безопасности. Конечно, как и раньше, его можно динамически менять через интерфейс IClientSecurity.

Задание уровня безопасности на стороне сервера

Конфигурируя серверное приложение, администратор должен задать (например, с помощью Component Services) ряд параметров, определяющих требования к уровню безопасности со стороны данного приложения:

• Будет ли контролироваться доступ к приложению? Если будет, то на каком уровне: только на уровне процесса или также и на уровне компонент?

При контроле доступа к приложению только на уровне процесса никакая информация об используемом уровне безопасности не будет включена в контекст объекта. Это делает невозможным наиболее тонкий программный контроль безопасности. Стандартным для СОМ+ является второй вариант, когда уровень доступа контролируется и на уровне отдельных компонент, интерфейсов и методов. В этом случае в контекст объекта включается информация, которая делает возможным программное управление безопасностью.

• Уровни аутентификации и имперсонализации

Заданный уровень аутентификации будет использоваться при переговорах между клиентским и серверным приложениями относительно реально используемого уровня аутентификации (используется максимальный из уровней аутентификации, заданных для клиента и сервера). Уровень имперсонализации используется в тех случаях, когда какой-либо поток данного приложения будет вызывать другое серверное приложение, выступая в роли клиента.

• Идентификационные данные

Исполняемое серверное приложение выступает в роли принципала со своими именем, паролем, SID. Ранее (в СОМ) серверное приложение могло запускаться под идентификацонными данными запустившего его клиента, но такое решение было признано немасштабируемым. В СОМ+ администратор выбирает один из двух вариантов:

♦ Интерактивный пользователь

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

♦ Заданный пользователь

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

• Роли

В СОМ+ механизм ролей используется при авторизации клиентов. Авторизация клиента означает выяснение его прав, связанных с запуском серверного приложения, с вызовом того или иного метода серверного объекта. При конфигурировании серверного приложения администратор определяет список ролей, которым могут принадлежать клиенты. Далее к каждой роли приписываются те или иные пользователи, зарегистрированные в домене. Удобно приписывать к одной роли целую группу пользователей (с заданным SID). Одной роли можно приписать многих пользователей, и один пользователь может исполнять несколько ролей. Классические примеры ролей: клерк, менеджер.

После распределения пользователей по ролям (относительно данного серверного приложения), администратор может приписать определенные роли приложению в целом, отдельным его компонентам, интерфейсам и методам. В результате, доступ к некоторому ресурсу (компоненту, интерфейсу, методу) получают только те клиенты, которые выполняются с SID пользователя, исполняющего соответствующую роль.

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

В связи с рассмотренным только что вопросом о ролях уместно более подробно остановиться на программируемом контроле доступа к приложению. Механизм ролей позволяет разрешить или запретить вызов некоторого метода некоторого серверного объекта всем клиентам, исполняющим определенную роль. Однако, в некоторых случаях желательно иметь более тонкий контроль на доступом, учитывающий не только роль клиента, но и значения параметров, которые этот клиент задал при вызове метода. В этом случае не обойтись без программируемого контроля на стороне сервера.

С каждым вызовом некоторого метода серверного объекта связан так называемый контекст безопасности вызова (конечно, для этого должны быть заданы роли, и некоторая роль должна быть приписана этому методу или содержащему его интерфейсу, компоненту, но не всему приложению). Имеется интерфейс ISecurityCallContext, через который можно получить доступ к этому контексту. Для получения указателя на этот интерфейс можно вызвать из потока, исполняющего данный метод, функцию CoGetCallContext. В качестве входного параметра задается идентификатор запрашиваемого интерфейса (ID_ISecurityCallContext), через выходной параметр возвращается указатель на