Если клиентское приложение не вызвало CoInitializeSecurity явно, эта функция будет вызвана автоматически при первом маршалинге интерфейса, который был инициирован данным приложением. При этом при задании уровня безопасности будут использованы параметры, заданные в локальной системе по умолчанию. При явном вызове этой функции клиентское приложение задает, в частности, следующие параметры:
• Уровень аутентификации, который будет использован в данном клиентском приложении по умолчанию
• Уровень имперсонализации, который будет использован в данном клиентском приложении по умолчанию
• Указатель на структуру, где для каждого из поддерживаемых данным приложением сервисов аутентификации (Kerberos, NT LAN Manager….), задается сервис авторизации (NULL для Kerberos) и аутентификационная информация. Для Kerberos это:
♦ Имя пользователя
♦ Пароль
Возможность задания аутентификационной информации позволяет клиентскому приложению пользоваться правами не того пользователя, который запустил это приложение, а пользователя, чьи данные указаны при вызове CoInitializeSecurity.
В случае, если клиентское приложение смогло запустить серверное (условия этого будут обсуждаться позднее), оно получит прокси на запрошенный интерфейс. Уровни аутентификации и имперсонализации задаются на уровне прокси. Первоначально они определяются значениями, принятыми по умолчанию, но могут быть изменены самим клиентом.
Значение уровня аутентификации определяется в результате переговоров клиентского и серверного приложений. Именно, итоговый уровень аутентификации равен максимальному из уровней аутентификации по умолчанию, определенными клиентским и серверным приложениями. Уровень имперсонализации определяется исключительно клиентским приложением.
Возможность динамического изменения установок уровня безопасности основана на использовании интерфейса IClientSecurity. Если разработка серверного приложения сопровождалась подготовкой IDL файла с описаниями всех интерфейсов всех классов, включенных в приложение, то прокси каждого интерфейса (код которого сгенерирован Microsoft IDL), реализует интерфейс IClientSecurity. Таким образом, получив указатель на любой интерфейс некоторого объекта серверного приложения, клиентское приложение может (используя QueryInterfасе) получить указатель на IClientSecurity. Данный интерфейс имеет следующие методы:
• Query Blanket
Используется для получения информации о текущем уровне безопасности, обеспечиваемом для всех вызовов, проходящих через данный прокси
• SetBlanket
Используется для задания нового уровня безопасности, который будет обеспечиваться для всех вызовов через данный прокси
• СоруРгоху
В некоторых случаях удобно использовать различные уровни безопасности при вызове различных методов одного и того же интерфейса. Например, вызов метода, среди параметров которого задается номер кредитной карты, должен выполняться с наивысшим уровнем аутентификации, при котором шифруются все передаваемые данные. Однако, использование такого уровня при выполнении всех вызовов через данный интерфейс может быть слишком накладно. Используя метод CоруРгоху можно скопировать прокси, повысить уровень безопасности для всех вызовов, проходящих через копию, а для всех вызовов, проходящих через исходный прокси, оставить прежний уровень безопасности.
Еще один способ динамического задания уровня безопасности связан с заданием необходимого уровня безопасности при вызове функции построения нового серверного объекта. Напомним, что при вызове функции CoGetClassObject один из входных параметров является указателем на структуру COSERVERINFO. До настоящего момента мы полагали, что этот параметр равен NULL. В этом случае имя машины, где установлено серверное приложение, ищется в реестре машины клиента, а требования к уровню безопасности со стороны клиента определяются уровнем безопасности по умолчанию, заданным администратором локальной машины.
Желая использовать иные, чем по умолчанию, требования к уровню безопасности, клиентское приложение может вызвать функцию CoGetClassObject с указателем на структуру COSERVERINFO, содержащую, в частности, следующие данные:
• Используемый при работе с данным объектом сервис аутентификации (например, Kerberos)
• Сервис авторизации (NULL в случае Kerberos)
• Уровни аутентификации и имперсонализации
• Указатель на структуру с аутентификационными данными:
♦ Имя пользователя
♦ Пароль
♦ Домен
В результате, при построении нового серверного объекта клиентское приложение получит прокси настроенный на специфицированный в COSERVERINFO уровень безопасности. Конечно, как и раньше, его можно динамически менять через интерфейс IClientSecurity.
Задание уровня безопасности на стороне сервера
Конфигурируя серверное приложение, администратор должен задать (например, с помощью Component Services) ряд параметров, определяющих требования к уровню безопасности со стороны данного приложения:
• Будет ли контролироваться доступ к приложению? Если будет, то на каком уровне: только на уровне процесса или также и на уровне компонент?
При контроле доступа к приложению только на уровне процесса никакая информация об используемом уровне безопасности не будет включена в контекст объекта. Это делает невозможным наиболее тонкий программный контроль безопасности. Стандартным для СОМ+ является второй вариант, когда уровень доступа контролируется и на уровне отдельных компонент, интерфейсов и методов. В этом случае в контекст объекта включается информация, которая делает возможным программное управление безопасностью.
• Уровни аутентификации и имперсонализации
Заданный уровень аутентификации будет использоваться при переговорах между клиентским и серверным приложениями относительно реально используемого уровня аутентификации (используется максимальный из уровней аутентификации, заданных для клиента и сервера). Уровень имперсонализации используется в тех случаях, когда какой-либо поток данного приложения будет вызывать другое серверное приложение, выступая в роли клиента.
• Идентификационные данные
Исполняемое серверное приложение выступает в роли принципала со своими именем, паролем, SID. Ранее (в СОМ) серверное приложение могло запускаться под идентификацонными данными запустившего его клиента, но такое решение было признано немасштабируемым. В СОМ+ администратор выбирает один из двух вариантов:
♦ Интерактивный пользователь
В этом случае запускаемое серверное приложение будет исполняться под идентификационными данными (и с правами) пользователя, имеющего в данный момент интерактивный сеанс на машине, где установлено серверное приложение. Это имеет свои плюсы и минусы. Удобен этот режим для отладки, для интерактивных приложений. Однако для неинтерактивных приложений этот способ опасен. Во-первых, серверное приложение может получить права администратора, если администратор в данный момент вошел в систему. Во-вторых, при выходе интерактивного пользователя из системы, серверное приложение, запущенное под идентификационными данными данного пользователя, будет также завершено,
♦ Заданный пользователь
В этом случае администратор задает для конкретного серверного приложения уникальные имя и пароль, регистрируя приложение как нового пользователя в системе с определенными правами. Передача прав клиента серверному приложению возможна через механизм имперсонализации.
• Роли
В СОМ+ механизм ролей используется при авторизации клиентов. Авторизация клиента означает выяснение его прав, связанных с запуском серверного приложения, с вызовом того или иного метода серверного объекта. При конфигурировании серверного приложения администратор определяет список ролей, которым могут принадлежать клиенты. Далее к каждой роли приписываются те или иные пользователи, зарегистрированные в домене. Удобно приписывать к одной роли целую группу пользователей (с заданным SID). Одной роли можно приписать многих пользователей, и один пользователь может исполнять несколько ролей. Классические примеры ролей: клерк, менеджер.