? Имя пользователя

? Пароль

? Домен

В результате, при построении нового серверного объекта клиентское приложение получит прокси настроенный на специфицированный в COSERVERINFO уровень безопасности. Конечно, как и раньше, его можно динамически менять через интерфейс IClientSecurity.

Задание уровня безопасности на стороне сервера

Конфигурируя серверное приложение, администратор должен задать (например, с помощью Component Services) ряд параметров, определяющих требования к уровню безопасности со стороны данного приложения:

• Будет ли контролироваться доступ к приложению? Если будет, то на каком уровне: только на уровне процесса или также и на уровне компонент?

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

• Уровни аутентификации и имперсонализации

Заданный уровень аутентификации будет использоваться при переговорах между клиентским и серверным приложениями относительно реально используемого уровня аутентификации (используется максимальный из уровней аутентификации, заданных для клиента и сервера). Уровень имперсонализации используется в тех случаях, когда какой-либо поток данного приложения будет вызывать другое серверное приложение, выступая в роли клиента.

• Идентификационные данные

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

? Интерактивный пользователь

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

? Заданный пользователь

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

• Роли

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

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

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

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

С каждым вызовом некоторого метода серверного объекта связан так называемый контекст безопасности вызова (конечно, для этого должны быть заданы роли, и некоторая роль должна быть приписана этому методу или содержащему его интерфейсу, компоненту, но не всему приложению). Имеется интерфейс ISecurityCallContext, через который можно получить доступ к этому контексту. Для получения указателя на этот интерфейс можно вызвать из потока, исполняющего данный метод, функцию CoGetCallContext. В качестве входного параметра задается идентификатор запрашиваемого интерфейса (ID_ISecurityCallContext), через выходной параметр возвращается указатель на этот интерфейс.