некоторые данные об удаленной машине, о клиенте, о требуемом уровне безопасности

• IID запрашиваемого интерфейса (обычно IID_IClassFactory)

Единственный выходной параметр при успешном выполнении вызова возвращает указатель на запрашиваемый интерфейс.

Самый интересный для нас параметр — указатель на структуру COSERVERINFO. Предположим для начала, что этот указатель равен NULL.

В этом случае вся связанная с данным вызовом информация на стороне клиента определяется по умолчанию:

• Имя машины

В реестре машины клиента под ключом CLSID должен иметься раздел для нужного класса (CLSID класса), а в нем подключен RemoteServerName, определяющий имя удаленной машины, на которой установлено приложение, содержащее этот класс.

• Уровень аутентификации

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

1. None

Аутентификация не выполняется. В этом случае клиент анонимен для сервера и никакого контроля за передаваемыми данными не проводится.

2. Connect

Именно этот уровень обычно выбирается администратором как уровень по умолчанию. Аутентификация клиента выполняется при первом соединении клиента с сервером. Защиты передаваемых данных нет.

3. Call

Аутентификация клиента выполняется при каждом вызове метода сервера. Выполняется защита от перехвата и прочтения передаваемых данных стандартными средствами. Для этого выполняется шифрование последовательных номеров передаваемых пакетов.

4. Packet

Аутентификация выполняется при пересылке каждого пакета. Шифруются номера передаваемых пакетов.

5. Packet lntegrity

Кроме того, что выполняется на предыдущем уровне, вычисляется, шифруется и передается контрольная сумма пакета. В результате контролируется целостность передаваемых данных.

6. Packet Privacy

В дополнение к функциональности предыдущего уровня выполняется шифрование всех передаваемых данных.

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

• Уровень имперсонализации

Этот уровень определяется только клиентским приложением (и серверным, когда оно выступает клиентом по отношению к другому серверному приложению). Уровень имперсонализации определяет объем прав доступа, которые клиентское приложение желает передать серверному.

Рассмотрим прежде всего сам механизм имперсонализации. После входа пользователя в систему все запускаемые (прямо и косвенно) им процессы имеют маркер доступа (access token), содержащий, в частности, такую информацию как SID (Security IDentifier) пользователя и SID всех груп, в которых зарегистрирован данный пользователь, а также различные его привилегии. Каждому локальному ресурсу приписан список ACL (Access Control List), содержащий элементы АСЕ (Access Control Entry), в каждом из которых разрешается или запрещается определенный набор способов доступа к данному ресурсу для некоторого SID. При попытке обращения некоторого потока к некоторому локальному ресурсу происходит последовательный просмотр ACL этого ресурса и все SID из маркера доступа процесса, содержащего данный поток, сопоставляются с SID из очередного АСЕ. Процесс просмотра ACL прекращается, как только выясняется, что данный поток обладает достаточными правами для доступа к ресурсу, либо, напротив, что доступ запрещается.

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

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

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. Если разработка серверного приложения