Дональд Бокс - Сущность технологии СОМ. Библиотека программиста

hr = CoSetProxyBlanket(pUnkProxyManager, RPC_C_AUTHN_NONE, RPC_C_AUTHZ_NONE, О, RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);

assert(SUCCEEDED(hr));

// set blanket for interface proxy

// устанавливаем защиту для интерфейсного заместителя

hr = CoSetProxyBlanket(pApe, RPC_C_AUTHN_NONE, RPC_C_AUTHZ_NONE, 0, RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_ANONYMOUS, 0, EOAC_NONE);

assert(SUCCEEDED(hr));

// release temporary pointer to proxy manager

// освобождаем временный указатель на администратор заместителей

pUnkProxyManager->Release();

}

Хотя представляется возможным установить и запросить защиту для администратора заместителей, невозможно скопировать администратор заместителей с помощью IClientSecurity::CopyProxy , так как это нарушило бы правила идентификации COM.

Когда ORPC-запрос направляется интерфейсной заглушке, COM создает объект контекста вызова ( call context object ), представляющий различные аспекты вызова, в том числе установки защиты того интерфейсного заместителя, который отправил этот запрос. COM связывает этот контекстный объект с потоком, который будет выполнять вызов метода. Библиотека COM выставляет API-функцию CoGetCallContext , позволяющую реализациям метода получить контекст для текущего вызова метода:

HRESULT CoGetCallContext ([in] REFIID riid, [out, iid_is(riid)] void **ppv);

В Windows NT 4.0 единственным интерфейсом, доступным для контекстного объекта вызова, является интерфейс IServerSecurity :

[local, object, uuid(0000013E-0000-0000-C000-000000000046)]

interface IServerSecurity : IUnknown {

// get caller's security settings

// получаем установки защиты вызывающей программы

HRESULT QueryBlanket( [out] DWORD *pAuthnSvc,

// authentication pkg

// модуль аутентификации

[out] DWORD *pAuthzSvc,

// authorization pkg

// модуль авторизации

[out] OLECHAR **pServerName,

// server principal

// серверный принципал

[out] DWORD *pAuthnLevel,

// authentication level

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

[out] DWORD *pImpLevel,

// impersonation level

// уровень заимствования прав

[out] void *pPrivs,

// client principal

// клиентский принципал

[out] DWORD *pCaps

// EOAC flags

// флаги EOAC

);

// start running with credentials of caller

// начинаем выполнение с полномочиями вызывающей программы

HRESULT ImpersonateClent(void);

// stop running with credentials of caller

// заканчиваем выполнение с полномочиями вызывающей программы

HRESULT RevertToSelf(void);

// test for Impersonation

// тест для заимствования прав BOOL

IsImpersonating(void);

}

IServerSecurity::QueryBlanket возвращает установки полной защиты, фактически использованные для текущего ORPC-вызова (которые могут несколько отличаться от клиентских установок благодаря специфическому для SSP повышению уровней). Как было в случае с IClientSecurity::QueryBlanket , функции IServerSecurity::QueryBlanket также разрешается передавать нуль вместо неиспользуемых параметров. Ниже приведен пример реализации метода, которая гарантирует, что вызывающая программа обеспечила возможность шифрования перед обработкой вызова:

STDMETHODIMP Gorilla::SwingFromTree(/*(in]*/ long nTreeID) {

// get current call context

// получаем контекст текущего вызова IServerSecurity *pss = 0;

HRESULT hr = CoGetCallContext(IID_IServerSecurity, (void**)&pss);

DWORD dwAuthnLevel;

if (SUCCEEDED(hr)) {

// get authentication level of current call

// получаем уровень аутентификации текущего вызова

hr = pss->QueryBlanket(0, 0, 0, &dwAuthnLevel, 0, 0, 0);

pss->Release(); }

// verify proper authentication level

// проверяем правильность уровня аутентификации

if (FAILED(hr) || dwAuthnLevel != RPC_C_AUTHN_LEVEL_PKT_PRIVACY)

hr = APE_E_NOPUBLICTREE;

else hr = this->ActuallySwingFromTree(nTreeID);

return hr;

}

Как было в случае с IClientSecurity , каждый метод IServerSecurity доступен в качестве удобной API-функции. Приводимая ниже реализация метода использует удобную подпрограмму вместо явного вызова интерфейса IServerSecurity

STDMETHODIMP Gorilla::SwingFromTree(/*[in]*/ long nTreeID) {

DWORD dwAuthnLevel;

// get authentication level of current call

// получаем уровень аутентификации текущего вызова

HRESULT hr = CoQueryClientBlanket(0, 0, 0, &dwAuthnLevel, 0, 0, 0);

// verify proper authentication level

// проверяем правильность уровня аутентификации

if (FAILED(hr) || dwAuthnLevel != RPC_C_AUTHN_LEVEL_РКТ_PRIVACY)

hr = АРЕ_Е_NOPUBLICTREE;

else hr = this->ActuallySwingFromTree(nTreeID);

return hr;

}

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

Метод IServerSecurity::QueryBlanket также позволяет разработчику объекта находить идентификатор защиты вызывающей программы через параметр pPrivs . Как и в случае с полномочиями, передаваемыми в IClientSecurity::SetBlanket , точный формат этого идентификатора является специфическим для конкретного модуля защиты. Для NTLM этот формат является просто строкой вида Authority\AccountName

Следующая реализация метода отыскивает идентификатор защиты вызывающей программы с помощью API-функции CoQueryClientBlanket :

STDMETHODIMP Gorilla::EatBanana() {

OLECHAR *pwszClientPrincipal = 0;

// get security identifier of caller

// получаем идентификатор защиты вызывающей программы

HRESULT hr = CoQueryClientBlanket(0, 0, 0, 0, 0, (void**)&pwszClientPrincipal, 0);

// log user name

// регистрируем имя пользователя

if (SUCCEEDED(hr)) {

this->LogCallerIDToFile(pwszClientPrincipal);

hr = this->ActuallyEatBanana();

}

return hr;

}

При вызове CoQueryClientBlanket для успешного возвращения идентификатора защиты вызывающей программы последняя должна определить:

По крайней мере RPC_C_IMP_LEVEL_IDENTIFY как автоматический (или явный) уровень заимствования прав;

По крайней мере RPC_C_AUTHN_LEVEL_CONNECT как автоматический (или явный) уровень аутентификации.

Если вызывающая программа явно изменила вызывающий принципал в установках полной защиты заместителя с помощью функции COAUTHIDENTITY , то вместо него будет возвращено имя явно заданного принципала.

Точно так же, как можно полностью контролировать установки защиты, использующиеся при вызове метода с помощью интерфейса IClientSecurity , представляется полезным контролировать установки защиты, использованные при вызове на активацию. К сожалению, активационные вызовы являются глобальными API-функциями, не имеющими соответствующего администратора заместителей, откуда можно было бы получить интерфейс IClientSecurity . Для того чтобы позволить вызывающим программам задавать установки защиты для активационных вызовов, каждый активационный вызов принимает структуру СОSERVERINFO :

typedef struct _COSERVERINFO {

DWORD dwReserved1;

LPWSTR pwszName; COAUTHINFO * pAuthInfo;

DWORD * dwReserved2;

} COSERVERINFO;

В одной из предыдущих глав было отмечено, что элемент данных pwszName позволяет вызывающей программе осуществлять явный контроль того, какая хост-машина будет обслуживать активационный запрос. Третий элемент данных, pAuthInfo , указывает на структуру данных, которая позволяет вызывающей программе контролировать установки защиты, использованные при осуществлении активационного вызова. Этот параметр является указателем на структуру COAUTHINFO , определенную следующим образом:

typedef struct _COAUTHINFO {

DWORD dwAuthnSvc;

DWORD dwAuthzSvc;

LPWSTR pwszServerPrincName;

DWORD dwAuthnLevel;

DWORD dwImpersonationLevel;

COAUTHIDENTITY * pAuthIdentityData;

DWORD dwCapabilities;

} COAUTHINFO;

Эти элементы данных соответствуют параметрам IClientSecurity::SetВlanket , однако используются только во время активационного вызова и не влияют на результирующий интерфейсный заместитель [4].