Ограничение доступа к COM+ компонентам

← →
Genry (2006-05-03 15:06) [0]

Доброго всем времени суток!
Есть приложение, работающее в трехзвенной архитектуре с использованием DataSnap
Серверные библиотеки под COM+, каждая на базе TMTSDataModule.
Вопрос заключается в следующем: возможно ли каким-то образом исключить прямое обращение к серверным компонентам? Скажем, некий юзер имеет права на запуск COM+ компонент. Нужно сделать так чтоб этот юзер смог реально с ними работать только из клиентской части приложения, предварительно пройдя авторизацию. Если он попытается самостоятельно вызвать какие-то методы (не из клиентского приложения)- получит ошибку.
Интересуют идеи, как это можно реализовать (если вобще можно), пускай даже если это будет связано со значительной переработкой серверной части.

Заранее спасибо!

← →
Ломброзо © (2006-05-05 01:41) [1]

разве что только если смастерить самопальную систему аутентификации и авторизации наподобие веб-систем. То бишь:
- клиент успешно аутентифицируется логином/паролем
- сервер генерирует некую случайную переменную, сохраняет её у себя и отдает клиенту (аналог cookie)
- клиент передает квиток (cookie) во все методы серверных объектов, сервер проверяет квиток и авторизует клиента, или же не автоизует, если квиток передан пустой, невалидный или устаревший.

Вообще не стоит огород городить. COM+ -это stateless объекты, а безопасность при работе с ними обеспечивается встроенными средстами OC.

← →
Genry (2006-05-05 12:07) [2]

> Ломброзо © (05.05.06 01:41) [1]

> разве что только если смастерить самопальную систему аутентификации

Спасибо, мне как раз именно такая идея и пришла в голову.

> Вообще не стоит огород городить. COM+ -это stateless объекты,

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

> а безопасность при работе с ними обеспечивается встроенными
> средстами OC.

Ну да, ограничение на уровне юзера, но кое-кто хочет чтоб этот юзер не мог вызвать методы компонент НЕ из задачи, а того ОС кажется не дает таких возможностей...

← →
Ломброзо © (2006-05-05 12:38) [3]

>Почему же, это от настроек зависит, может быть stateless,
>может быть и statefull

В том-то и дело, что если мудрить с тонкими настройками, то все преимущества COM+ по сравнению с DCOM теряют смысл. Eсли отключить пулинг, то теоретически можно держать ссылку на COM+ объект сколь угодно долго, не опасаясь того, что сервер при очередном обращении не подсунет не используемый объект из пула, но я в этом не уверен :) Поищите в спецификации COM+ гарантии такого поведения.

* * *
По сабжу пришла в голову ещё одна идейка.
Предлагаю сделать вот что:
1) Создать компонент, осуществляющий аутентификацию пользователя, с единственным методом, ну например, Login
void Login([in] BSTR userId, [in] BSTR password);

2) В базе данных смастерить табличку
DomainLogonName (к примеру, DOMAIN\ivanov)
UserId (например, ivanov)
Password
LastLogonTime
LoggedIn

3) Включить для приложения принудительную проверку доступа (настройка приложения->Вкладка "Безопасность" и опцию "Проверка доступа на уровне приложения и компонента", то есть - делаем доступным контекст вызова безопасности COM+
4) В момент вызова пользователем метода Login нужно получить его Account Name из контекста безопасности и при успешной аутентификации записать в табличку время аутентификации (LastLogonTime) и признак того, что аутентификация выполнена (LoggedIn).

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

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

← →
Genry (2006-05-05 13:09) [4]

> что текущий пользователь прошёл аутентификацию и его сессия
> не завершилась по тайм-ауту.

Хм... идейка-то отличная, но тут есть тонкий момент: в таблице нужно отслеживать не только логин, но и логаут, чтобы понять что пользователь вышел из системы. Тогда как быть со случаем, когда произошел, скажем, разрывом соединения? В таблице останется запись о логине и всё...

> Eсли отключить пулинг, то теоретически можно держать ссылку
> на COM+ объект сколь угодно долго

Ну, я вобще-то говорил об отключении активации Just-in-time, тогда объект не пересоздается и способен сохранять свое состояние в течение всей коннекции к нему... или я ошибаюсь?

← →
Genry (2006-05-05 13:28) [5]

И еще, как быть с таким: юзеру на комп запустили трояна, дождались пока он залогинится в задаче и спокойно стали дергать этим трояном любые компоненты с сервера. Серверная компонента получает тот же Account Name из контекста и спокойно дает ему выкачивать все данные...

← →
Ломброзо © (2006-05-05 13:31) [6]

Лог-аут отслеживать не нужно, зачем? Я считаю, что программирование под COM+ во многом схоже с программированием под Web, поэтому все паттерны в принципе можно заимствовать оттуда. В Web существует понятие сессии и её времени жизни (час, сутки и т.д.), поэтому пока сессия жива, клиент работает, сессия истекла - добро пожаловать на повторную аутентификацию, а отслеживать логауты в многозвенках не правильно в принципе, и тем более в тех многозвенках, где соединение с сервером не постоянно.

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

> Eсли отключить пулинг, то теоретически можно держать ссылку
> на COM+ объект сколь угодно долго
Ну да, я имел в виду отключить и пулинг, и JIT.

← →
Ломброзо © (2006-05-05 13:33) [7]

Genry (05.05.06 13:28) [5]

Ну тогда остается только первый вариант, с квитком, гоняемым между клиентом и сервером.

← →
Genry (2006-05-05 13:51) [8]

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

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

> Ломброзо © (05.05.06 13:33) [7]

> Ну тогда остается только первый вариант

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

>Genry (05.05.06 13:51) [8]

Определить гд-нибудь продолжительность сессии, к примеру, 15 минут.
Далее несложная математика:
LogonTime = 10:00
SessionExpired = 10:15

если пользователь обратился, к примеру, в 10:12, то сессия не устарела, и в этом случае её можно продлить ещё на 15 минут (при необходимости можно перегенерировать квиток), а если в 10:16 - то заставить пройти аутентификацию повторно.

Насчёт трояна - отчего бы не посылать на сервер вместе с логином и паролем идентификатор клиентского процесса, работающего с сервером и проверять его тоже?

← →
Genry (2006-05-05 14:47) [10]

> Ломброзо © (05.05.06 14:03) [9]

> Определить гд-нибудь продолжительность сессии, к примеру,
> 15 минут.

Теперь понятно. Примерно так как сделано на некоторых веб-сайтах. Залогинился, если не дергаешь никакие ссылки в течении нек-рого времени - тебя просят повторно перелогиниться.
Тоже хороший вариант :-)

> Насчёт трояна - отчего бы не посылать на сервер вместе с
> логином и паролем идентификатор клиентского процесса, работающего
> с сервером и проверять его тоже?

Чесно говоря я вначале надеялся, что идентификатор клиентского процесса можно каким-то образом получить изнутри серверного объекта (подобно имени аккаунта), но ничего такого не нашел. Так бы конечно можно было бы прям из объекта привязаться к имени клиентского приложения, это было бы очень неплохо...
Ну а если реализовать обмен квитками, то есть ли смысл передавать еще и ID процесса?

Ограничение доступа к COM+ компонентам Найти похожие ветки