Страница 199 из 372
Объем передаваемых прав определяет сам клиент. В нашем случае (все параметры заданы по умолчанию) уровень имперсонализации для всех вызовов с данной машины на на удаленные машины определяет администратор. Вот возможные значения для этого уровня:
1. Anonimous
Данный уровень, при котором клиент анонимен для сервера, не используется
2. Identity
Идентификационная информация о клиенте известна серверу, но ее недостаточно для доступа к локальным ресурсам от лица клиента. Именно этот уровень обычно выбирается администратором как уровень имперсонализации по умолчанию.
3. Impersonate
Данный уровень имперсонализации достаточен для того, чтобы сервер мог получать доступ ко всем локальным ресурсам от лица клиента. Это наивысший уровень имперсонализации для SSP NT LAN Manager.
4. Delegate
При этом уровне сервер может делать удаленные вызовы от лица клиента. Этот уровень появился в SSP Kerberos.
Что делать, если уровни аутентификации и имперсонализации, установленные по умолчанию администратором данной конкретной машины, не устраивают клиентское приложение? Имеются два выхода:
• Клиентское приложение задает собственный уровень безопасности по умолчанию в рамках своего процесса
• Клиентское приложение может динамически менять свои требования к уровню безопасности в процессе выполнения.
Для задания собственного уровня безопасности по умолчанию в рамках своего процесса клиентское приложение может вызвать функцию CoInitializeSecurity. Серверное COM+ приложение не должно вызывать эту функцию, т. к. она вызывается автоматически и вторичный ее вызов завершится ошибкой.
Если клиентское приложение не вызвало 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) ряд параметров, определяющих требования к уровню безопасности со стороны данного приложения:
• Будет ли контролироваться доступ к приложению? Если будет, то на каком уровне: только на уровне процесса или также и на уровне компонент?
При контроле доступа к приложению только на уровне процесса никакая информация об используемом уровне безопасности не будет включена в контекст объекта. Это делает невозможным наиболее тонкий программный контроль безопасности. Стандартным для СОМ+ является второй вариант, когда уровень доступа контролируется и на уровне отдельных компонент, интерфейсов и методов. В этом случае в контекст объекта включается информация, которая делает возможным программное управление безопасностью.
• Уровни аутентификации и имперсонализации
Заданный уровень аутентификации будет использоваться при переговорах между клиентским и серверным приложениями относительно реально используемого уровня аутентификации (используется максимальный из уровней аутентификации, заданных для клиента и сервера). Уровень имперсонализации используется в тех случаях, когда какой-либо поток данного приложения будет вызывать другое серверное приложение, выступая в роли клиента.
• Идентификационные данные