Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Модель с точки зрения разработчика

Читайте также:
  1. I. Гений с объективной точки зрения
  2. II. Гений с субъективной точки зрения
  3. III.I. Механистическая модель.
  4. III.II. Органическая модель.
  5. Mitsubishi Lancer X 2007, кузов CX.CY, двс 2.0, модель 4B11, АКПП
  6. Quot;Элементарная модель" типа ИМ
  7. V. Модель выпускника

Разумеется, здесь разговор пойдет только о таких приложениях, которые явно используют те или возможности Сервиса Безопасности. Средства, предоставляемые этим сервисом, позволяют решать следующие задачи:

Начнем с задания удостоверений и аутентификации.


Рисунок 11.7

Основой для выполнения аутентификации (если она необходима) является объект Credentials. Пути создания и настройки этого объекта могут быть различными. Например, если принципал уже аутентифицирован, то для получения объекта Credentials можно использовать интерфейс Current. Напоминаем, что интерфейсы Current, определенные в различных сервисах CORBA, в принципе предназначены для решения одной задачи, а именно: они позволяют получить доступ к информации, передаваемой по ORB, в контексте (и потоке) текущего вызова. Интерфейс Current Сервиса Безопасности обеспечивает доступ к параметрам, связанным с безопасностью (подобно тому, как интерфейс Current Сервиса Объектных Транзакций обеспечивает доступ к параметрам текущей транзакции).

В общем случае, т.е. тогда, когда принципал (User на приведенном выше рисунке) должен быть аутентифицирован, но еще не аутентифицирован.

User Sponsor (который нарисован с использованием пунктирной линии потому, что это не CORBA-интерфейс, а некоторый фрагмент кода приложения) получает от пользователя необходимые данные (например, учетное имя и пароль), а затем обращается к объекту Principal Authenticator, который проводит аутентификацию и в качестве ее результата получает объект Credentials, который содержит идентификатор принципала и его привилегии. Как правило (но не обязательно!) эти действия выполняются в клиентском приложении.

После того, как все необходимые удостоверения заданы для данного принципала, они используются при выполнении защищенных вызовов. Программист может при необходимости менять эти удостоверения. Сделать это можно двумя способами: либо изменить состояние соответствующего объекта Credentials (для чего предусмотрен метол set_attributes()), либо изменив политики на уровне самой объектной ссылки обычными средствами управления политиками CORBA (за режим привилегий при вызове отвечает политика InvocationCredentialsPolicy, рисунок 9.8).


Рисунок 11.8

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

Что касается собственно выполнения защищенного удаленного вызова, то здесь все внешне выглядит, как обычно – все необходимое с точки зрения параметров безопасности выполняется ORB’ом и Сервисом Безопасности без участия самих приложений – как клиента, так и сервера.


Рисунок 11.9

Security Service перехватывает вызов и с помощью интерфейса Current получает доступ ко всем атрибутам объекта Credentials.


Рисунок 11.10

Переходим на сторону сервера. Там выполняются похожие действия –Security Service перехватывают пришедший по ORB’у запрос. Получить доступ к параметрам безопасности – идентификатору принципала и его привилениям – можно с помощью вызова метода get_attributes() интерфейса Current. Далее эти привилегии используются при принятии решения, можно ли разрешить доступ данному принципалу в контексте этого вызова к данному серверному объекту (т.е. выполняется авторизация), см. рисунок 11.10.

Похожие механизмы используются и в случае, когда имеет место цепочка вызовов, т.е. некоторый промежуточный объект выступает сначала в роли сервера, а затем, при последующем вызове – уже в роли клиента. Если приложение использует API Security Service, то промежуточный объект может анализировать параметры безопасности пришедшего запроса и, в случае необходимости, менять из перед выполнением следующего вызова в цепочке. Для этой цели опять используется интерфейс Current:

Рисунок 11.11

Для получения привилегий, содержащихся в полученном запросе, удобно использовать атрибут received_credentials интерфейса Current.

Промежуточный объект может быть самостоятельным принципалом и выполнять последующий вызов «от собственного имени». Это означает, что он должен получить свой объект Credential вместо того, чтобы извлекать существующий в контексте пришедшего запроса объект с помощью Current. В этом случае промежуточный объект обращается к методу authenticate() объекта PrincipalAuthenticator, а затем настраивает его с помощью метода set_attributes() объекта Credentials.

Что касается других аспектов управления приложением – принятия решений о предоставлении доступа или выполнении аудита – то спецификация не предусматривает объявления определенных политик и не занимается строгой формализацией этих процессов. Тем не менее, CORBA Security Service предоставляет некоторые стандартные вспомогательные объекты, например, AuditChannel – логический канал вывода информации, или AuditDecision (для принятия решения, нужно ли отслеживать определенное событие), которые удобно использовать в системе аудита,


Дата добавления: 2015-08-13; просмотров: 80 | Нарушение авторских прав


Читайте в этой же книге: Отличие промышленных систем от игрушечных | Без дисциплины работать трудно | Администрирование распределенных систем на примере Oracle | История создания OMG и стандарта CORBA | Кодирование составных типов | Object Services - объектные сервисы | Обзор протоколов GIOP и IIOP | Безопасность в CORBA | Структура CORBA Security Service | Делегирование в CORBA Security Service |
<== предыдущая страница | следующая страница ==>
Домены безопасности| Основные политики безопасности

mybiblioteka.su - 2015-2024 год. (0.006 сек.)