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

Наконец, используя Components Services, можно пометить некоторый метод как Auto-Done. В этом случае при возврате из этого метода произойдет деактивация объекта и он будет голосовать за успешное завершение текущей транзакции или за откат в зависимости от того, завершился ли вызов данного метода нормально или с ошибкой. При использовании указанных выше интерфейсов этот режим перекрывается явным заданием битов голосования и деактивизации.

Распространение транзакции происходит как обычно путем активации новых объектов и путем обращения к системам хранения данных. В последнем случае соответствующий менеджер ресурса регистрируется у DTC для участия в текущей транзакции.

Завершение транзакции

Завершается транзакция в следующих случаях

• Корневой объект транзакции деактивирован после возврата из метода, где был установлен бит деактивации

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

Если хотя бы для одного объекта бит голосования равен 0, выполняется откат назад без выполнения двух-фазного протокола.

• Корневой объект был уничтожен в связи с тем, что клиент освободил все указывающие на объект ссылки

В этом случае DTC завершает транзакцию и выполняется откат назад без выполнения двух-фазного протокола.

• Закончился временной интервал, выделенный на текущую транзакцию

По умолчанию длительность транзакции не превышает 60 секунд. По их истечении DTC завершает транзакцию и выполняется откат назад без выполнения двух-фазного протокола.

Безопасность

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

Различные протоколы безопасности могут быть реализованы в виде динамически компонуемых библиотек, так называемых провайдеров сервиса безопасности (SSP — Security Service Provider). Каждый SSP должен реализовать стандартный API — интерфейс провайдера поддержки безопасности (SSPI — Security Support Provider Interface), который изолирует распределенное приложение от конкретного протокола безопасности и позволяет повышать уровень безопасности используя более совершенные протоколы.

В следующем разделе рассматривается протокол Kerberos, который является протоколом по умолчанию для Windows 2000 и наилучшим на сегодня образом удовлетворяет потребности в обеспечении безопасности распределенных СОМ+ приложений. Заметим, что в СОМ+ может использоваться также протокол NT LAN Manager, который использовался ранее в СОМ приложениях, исполняемых под Windows NT. Однако, данный протокол не обеспечивает всех возможностей, предоставляемых протоколом Kerberos, в том числе тех, которые особенно важны для распределенных приложений с трех-уровневой архитектурой (взаимная аутентификация клиента и сервера, делегирование).

Kerberos

Kerberos является протоколом, обеспечивающим безопасность функционирования распределенного приложения. Разработан этот протокол в начале 80-х годов в Массачусетском технологическом институте и в настоящее время принят как стандарт, поддерживаемый различными независимыми производителями программного обеспечения. С этим стандартом можно познакомиться по RFC 1510. Windows 2000 реализует этот стандарт, и далее рассматривается именно эта реализация — Windows 2000 Kerberos. Основой для данного раздела является статья David Chappel "Exploring Kerberos, the Protocol for Distributed Security in Windows 2000", Microsoft System Journal, August 1999.

Основные сервисы

Любая реализация Kerberos обеспечивает следующие сервисы:

• Аутентификация

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

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

Реализация Kerberos в Windows 2000 поддерживает два алгоритма шифрования:

♦ DES — Data Encription Standard

Это первый официально предложенный правительством США стандарт в области шифрования, предназначенный для коммерческого использования. Длина ключа равна 64 битам, из которых 8 используются для контроля ошибок, и, следовательно, эффективная длина ключа равна 56 битам.

♦ RC4

Более быстрый алгоритм шифрования потока данных с ключом переменной длины. Именно этот алгоритм используется по умолчанию в Windows 2000 Kerberos. Длина ключа в версиях, используемых на территории США, равна 128 бит, а за пределами США — 56 бит.

• Проверка целостности данных

Здесь имеется ввиду, что получатель данных должен быть уверен, что в процессе передачи данные не были изменены. Реализация данного требования основана на вычислении контрольной суммы для каждого передаваемого пакета данных, которая в зашифрованном виде передается вместе с ним. Контрольная сумма есть значение некоторой функции от передаваемых данных, имеющей различные значения на различных данных. В Kerberos для вычисления контрольной суммы используется НМАС — Hash-based Message Authentication Code. Передача зашифрованной контрольной суммы гарантирует, что искажение (случайное или умышленное) передаваемых данных будет обнаружено на принимающей стороне.

• Шифрование трафика

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

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

Основные сценарии использования сервисов Kerberos

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

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

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

Рассмотрим основные поля данных билета:

• Нешифруемые поля

♦ Домен