Транспорт для протокола GIOP

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

1. Транспорт ориентируется на установление соединения с последующим обменом информации в рамках соединения. Соединение используется для определения правил нумерации запросов.

2. Транспорт протокол должен гарантировать прохождение переданных байт в том порядке, в котором они были посланы.

3. Транспорт может рассматриваться как поток байт без дополнительных ограничений на размеры, фрагментацию или выравнивание размеров посылок.

4. Транспорт должен обеспечивать сигнализацию об разрыве соединения. Если один из участников обмена неожиданно прервал свою работу, произошел сбой в операционной системе или сети, то другой должен быть уведомлен об этом.

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

Вовсе не обязательно конкретный транспорт должен прямо реализовывать все перечисленные требования, но должна иметься возможность для эмулирования описанной транспортной модели.

Управление соединением

Соединение двунаправленное в смысле потока данных, но оно не является симметричным в плане обмена сообщениями GIOP. Сообщения Request, LocateRequest и CancelRequest могут посылаться только клиентом. Сообщения Reply, LocateReply и CloseConnection - только сервером. Сообщение ErrorMessage может быть послано обеими сторонами. Через соединение для обмена в соответствии с протоколом GIOP могут посылаться только сообщения GIOP.

Каждое сообщение типа Request должно иметь уникальный номер, который идентифицирует запрос в рамках установленного соединения. Этот номер никоим образом не интерпретируется сервером, но он позволяет клиенту установить соответствие между запросом и пришедшим ответным сообщением в случае инициации сразу нескольких запросов. Генерация этих уникальных номеров возлагается на клиента.

Соединение может быть либо закрыто в рамках протокола, либо разорваться. Закрытие соединения может инициироваться со стороны сервера посредством посылки сообщения CloseConnection или клиентом посредством обычного закрытия соединения в произвольный момент времени. Если на момент закрытия соединения имеются неотработанные запросы, то сервер должен рассматривать такие запросы как отмененные. Сервер не может послать сообщение CloseConnection, если он начал обработку запроса, для которого не поступило сообщения CancelRequest, или он (сервер) не послал ответного сообщения.

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

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

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

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

• На кого – разработчиков системных средств или прикладных программ – возлагать главную часть обязанностей с точки зрения обеспечения безопасности?
• Как обеспечить оптимальное сочетание универсальности решения с его гибкостью, эффективностью и надежностью?
• Как обеспечить возможность (и простоту) использования в универсальной системе обеспечения безопасности уже хорошо зарекомендовавших себя различных технологических решений и подходов?
• Как обеспечить взаимодействие приложений, использующих различные реализации систем обеспечения безопасности?
• Как организовать относительно простое и удобное управление безопасностью для менеджеров информационных систем?
• Как обеспечить взаимодействие подсистем с различными уровнями обеспечения безопасности?
• Как удовлетворить требованиям обеспечения безопасности с учетом того, что требуемый уровень обеспечения безопасности очень сильно отличается для различных систем;
• Как предложить разработчикам универсальное и эффективное решение по доступной цене?

Система обеспечения безопасности в CORBA (CORBA Security Service) должна была дать ответы на эти и многие другие вопросы. Она разрабатывалась долго, примерно в течение двух лет, и первая версия была принята в самом конце 1995 года. В ее разработке принимали участие специалисты из AT&T, DEC, Expersoft, Hewlett-Packard, IBM, Novell, Siemens, Sunsoft, Tivoli Systems и других компаний. В настоящий момент последней утвержденной является версия 1.8 (принята в марте 2002 года). Номер версии говорит о том, что с момента появления в сервис не вносилось кардинальных изменений, хотя появление новых спецификаций сервисов CORBA требовало учета новых реалий и разработки улучшенных версий Security Service.

Как и следовало ожидать, Security Service построен по «драйверному» принципу – спецификация содержит большое количество IDL-интерфейсов, не задавая существенных ограничений с точки зрения их реализаций. Особенностью Security Service является специфическая «область применения» интерфейсов. Б о льшая их часть не интересует прикладных программистов – она предназначена, в первую очередь, для создателей самой реализации Сервиса Безопасности. Другая группа интерфейсов может использоваться прикладными разработчиками, если это необходимо в том или ином конкретном случае. Третья группа предназначена для обеспечения управления настройками системы на этапе ее функционирования и, следовательно, интересует, в первую очередь, администраторов систем, а также разработчиков утилит и приложений для администраторов.

Полная реализация всех – обязательных и необязательных – интерфейсов CORBA Security Service – является сложной, ресурсоемкой и дорогостоящей задачей. В настоящий момент на рынке присутствуют несколько достаточно полно соответствующих стандарту реализаций Security Service, такие, как ORBAsec компании Adiron, IONA OrbixSecurity, MICOSec от ObjectSecurity (соответствуют Security Level 2 версии 1.7 спецификации Security Service). Компания Borland предлагает расширенную службу обеспечения безопасности – Borland Security Service, сочетающую базовые возможности Security Service CORBA с реализацией безопасности в стандартах Java. Ограниченные реализации последних версий Security Service поставляются для TAO и других некоммерческих реализаций CORBA.

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

Основные понятия CORBA Security Service

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

Принципал (principal)

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

К сожалению, с использованием термина «принципал» часто происходит путаница. Связано это и со стилем самой спецификации, и с тем, что похожая терминология используется в Java-стандартах распределенных систем, а многие Java- технологии очень сильно связаны с CORBA.

Спецификация Security Service часто вместо «принципала» использует (практически как синоним) термин «субъект» (subject). Можно встретить и такую трактовку понятий «принципал» и «субъект»: субъект – это пользователь или объект, который необходимо идентифицировать перед началом собственно взаимодействия. Если субъект прошел процедуру идентификации, то с ним сопоставляются права, и этот субъект уже называется принципалом.

В Java Authentication and Authorization Service (JAAS) тоже используются термины «принципал» и «субъект», но несколько в ином значении. Кроме того, формализация этих понятий в JAAS более строгая. В JAAS субъект является совокупностью принципалов, причем под принципалом понимается некоторое имя, сопоставленное с объектом, участвующим во взаимодействии. Другими словами, один субъект (subject) JAAS может при обращении к разным сервисам выступать под разными именами, и каждое такое имя является принципалом.

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