 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| Модель с точки зрения разработчика
Разумеется, здесь разговор пойдет только о таких приложениях, которые явно используют те или возможности Сервиса Безопасности. Средства, предоставляемые этим сервисом, позволяют решать следующие задачи:
Начнем с задания удостоверений и аутентификации.
Основой для выполнения аутентификации (если она необходима) является объект Credentials. Пути создания и настройки этого объекта могут быть различными. Например, если принципал уже аутентифицирован, то для получения объекта Credentials можно использовать интерфейс Current. Напоминаем, что интерфейсы Current, определенные в различных сервисах CORBA, в принципе предназначены для решения одной задачи, а именно: они позволяют получить доступ к информации, передаваемой по ORB, в контексте (и потоке) текущего вызова. Интерфейс Current Сервиса Безопасности обеспечивает доступ к параметрам, связанным с безопасностью (подобно тому, как интерфейс Current Сервиса Объектных Транзакций обеспечивает доступ к параметрам текущей транзакции). В общем случае, т.е. тогда, когда принципал (User на приведенном выше рисунке) должен быть аутентифицирован, но еще не аутентифицирован. User Sponsor (который нарисован с использованием пунктирной линии потому, что это не CORBA-интерфейс, а некоторый фрагмент кода приложения) получает от пользователя необходимые данные (например, учетное имя и пароль), а затем обращается к объекту Principal Authenticator, который проводит аутентификацию и в качестве ее результата получает объект Credentials, который содержит идентификатор принципала и его привилегии. Как правило (но не обязательно!) эти действия выполняются в клиентском приложении. После того, как все необходимые удостоверения заданы для данного принципала, они используются при выполнении защищенных вызовов. Программист может при необходимости менять эти удостоверения. Сделать это можно двумя способами: либо изменить состояние соответствующего объекта Credentials (для чего предусмотрен метол set_attributes()), либо изменив политики на уровне самой объектной ссылки обычными средствами управления политиками CORBA (за режим привилегий при вызове отвечает политика InvocationCredentialsPolicy, рисунок 9.8).
В обоих случаях эффект изменений распространяется на все последующие вызовы с использованием данного объекта Credentials и/или данной объектной ссылки. Что касается собственно выполнения защищенного удаленного вызова, то здесь все внешне выглядит, как обычно – все необходимое с точки зрения параметров безопасности выполняется ORB’ом и Сервисом Безопасности без участия самих приложений – как клиента, так и сервера.
Security Service перехватывает вызов и с помощью интерфейса Current получает доступ ко всем атрибутам объекта Credentials.
Переходим на сторону сервера. Там выполняются похожие действия –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 (для принятия решения, нужно ли отслеживать определенное событие), которые удобно использовать в системе аудита, |
