Система безопасности Zope3

Фреймворк безопасности предоставляет общий механизм для реализации политики безопасности Python объектов. Это введение предоставляет учебный материал раскрывающий концепции фреймворка, примеры использования в перспективе нацеленный на Python разработчиков использующих фреймворк отдельно от Zope.
Введение -------- Фреймворк безопасности предоставляет общий механизм для реализации политики безопасности Python объектов. Это введение представляет собой учебный материал, раскрывающий концепции фреймворка, примеры использования в перспективе нацеленные на Python разработчиков, использующих фреймворк отдельно от Zope. Определения ----------- Principal ~~~~~~~~~ Обобщенная концепция пользователя, принципал. Permission ~~~~~~~~~~ Разновидность доступа, т.к. полномочие на ЧТЕНИЕ (READ) в противоположность полномочию на ЗАПИСЬ (WRITE). Фундаментально весь фреймворк безопасности организован на проверке полномочий для объектов. Назначение ---------- Основным назначением фреймворка безопасности является защита и проверка доступа Python объектов. Он не предоставляет механизма явной или неявной проверки доступа к атрибутам объектов. Имена атрибутов отображаются на имена полномочий когда проверяется доступ и выполняется проверка безопасности определенная политикой безопасности, которая получает имя полномочия (permission) и взаимодействие (interaction). Взаимодействия являются объектами представляющими в системе одного или нескольких пользователей. Взаимодействие содержит список участий (participation), каждое участие представляет из себя одно из действий пользователя (principal) во взаимодействии. Запрос HTTP является одним из примеров участия (participation). Важно помнить, что эта политика, предоставляемая только по умолчанию, и может быть заменена, так что надо быть внимательнее к пользователям (principals) и взаимодействиям (interactions). Компоненты фреймворка --------------------- Низкоуровневые компоненты ~~~~~~~~~~~~~~~~~~~~~~~~~ Эти компоненты предоставляют инфраструктуру для защиты доступа к атрибутам и предоставляют возможности (hooks) управления для высокоуровных компонентов фреймворка безопасности. Контроллеры (checkers) ~~~~~~~~~~~~~~~~~~~~~~ Контроллер ассоциирован с видом объекта, и предоставляет хуки для проверки отображений (карты) атрибута на полномочия отложенной для менеджера безопасности выполняющего проверку. Дополнительно, предоставляются контроллеры для прокси из объектов ассоциированных с контроллером. Доступны несколько вариантов реализации контроллеров, одна из реализаций - это контроллеры защищающий доступ на основе имен атрибутов. Прокси ~~~~~~ Обертки вокруг Python объектов, которые неявно защищают доступ к обернутому содержимому делегируя его ассоциированному контроллеру. Прокси являются вирусными по натуре, некоторые значения возвращаемые прокси, также являются прокси. Высокоуровневые компоненты -------------------------- Управление безопасностью ~~~~~~~~~~~~~~~~~~~~~~~~ Предоставляют средства доступа для установки взаимодействий и глобальной политики безопасности. Взаимодействие (Interaction) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Сохраняет временную информацию о списке участий. Участие (Participation) ~~~~~~~~~~~~~~~~~~~~~~~ Сохраняет информацию о пользователе (principal), участвующем во взаимодействии. Политика безопасности ~~~~~~~~~~~~~~~~~~~~~ Предоставляет единый метод принимающий объект, полномочие, и взаимодействие проверяющий доступ, и используется для реализации логики приложения для фреймворка безопасности. Изложение (песочница агента) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Как пример, мы рассмотрим конструирование многоагентсткой распределенной системы, и затем добавим уровень безопасности использующий модель безопасности Zope. Сценарий ~~~~~~~~ Наша симуляция состоит из автономных агентов, которые "живут" в множестве агентских песочницах (домашних каталогах) и выполняют действия доступа к сервисам доступным в их текущей песочнице. Агенты находятся в окружении токенов аутентификации, которые означают их уровень доступа к каждой из представленных песочниц. В дополнение агенты пытаются мигрировать из песочницы - в песочницу случайным образом. Симуляция агента была сконструирована отдельно от какого-либо из аспектов безопасности. Сейчас мы хотим определить и интегрировать модель безопасности в симуляцию. Полный код для симуляции и модели безопасности доступен по отдельности; мы приводим здесь только относящиеся к делу куски кода для иллюстрации того как мы проходим через процесс реализации. Для симуляции агента мы хотим добавить модель безопасности в которой мы группируем агентов в две группы аутентификации, "norse legentds", включающую принципалов thor, odin, и loki, и группу "greek men", включающую prometheus, archimedes, и thucydides. Мы ассоциируем полномочия с доступом к сервисам и песочницам. Мы различаем песочницы только для конкретных групп имеющих доступ к сервисам и песочницы основанные на локальных установках находящихся в этих песочницах. Определяем домашние каталоги/песочницы - oridgin - все агенты стартуют отсюда, и имеет здесь доступ ко всем сервисам; - valhalla - только агенты из группы 'norse legend' могут находится здесь; - jail - все агенты могут входить сюда, но только 'norse legend' могут перемещаться или иметь доступ к сервисам. Процесс ~~~~~~~ В свободной форме определяем процесс реализации модели безопасности - отображаем полномочия на действия; - отображаем токены аутентификации на полномочия; - реализуем контроллеры для политики безопасности, которые используются нашими токенами аутентификации и полномочиями; - связываем контроллеры с нашими классами симуляции; - вставляем руки в оригинальный код симуляции добавляющий прокси обертки для автоматической проверки безопасности; - вставляем хуки в оригинальный код симуляции регистрирующий агентов как активных принципалов во взаимодействие. Определение модели полномочий ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Мы определяем следующие полномочия:: NotAllowed = 'Not Allowed' Public = Checker.CheckerPublic TransportAgent = 'Transport Agent' AccessServices = 'Access Services' AccessTimeService = 'Access Time Service' AccessAgentService = 'Access Agent Service' AccessHomeService = 'Access Home Service' и создаем словарь отображающий песочницы для аутентифицированных групп которые связанны с ассоциированными полномочиями. Определение и связывание контроллеров ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Контроллеры являются фундаментальными модулями для фреймворка безопасности. Они определяют, какие атрибуты могут быть получены и установлены у конкретного экземпляра объекта. Они могут быть использованы неявно через прокси объекты, для защиты доступа ко всем атрибутам автоматически или явно для проверки соответствующего доступа для операций. Структура контроллера ожидает две функции словаря, один используется для отображения имен полномочий для доступа к атрибуту и другой тождественный для установки значений атрибутов. Мы используем следующую фабрику-функцию контроллера:: def PermissionMapChecker(permissions_map={}, setattr_permission_func=NoSetAttr): res = {} for k, v in permissions_map.items(): for iv in v: res[iv] = k return checker.Checker(res.get, setattr_permission_func) time_service_checker = PermissionMapChecker( # permission : [methods] {'AccessTimeService':['getTime']} ) функция NoSetAttr определена как lambda которая всегда возвращает полномочие NotAllowed. Для связывания контроллеров с классами симуляции мы регистрируем наши контроллеры с моделью безопасности в глобальном реестре контроллера:: import sandbox_simulation from zope.security.checker import defineChecker defineChecker(sandbox_simulation.TimeService, time_service_checker) Определение политики безопасности ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Мы реализуем нашу политику безопасности так что она проверяет текущие токены агентской аутентификации в зависимости от предоставленных полномочий в песочнице существующих для доступа к объекту:: class SimulationSecurityPolicy: implements(ISecurityPolicy) createInteraction = staticmethod(simpleinteraction.createInteraction) def checkPermission(self, permission, object, interaction): home = object.getHome() db = getattr(SimulationSecurityDatabase, home.getId(), None) if db is None: return None allowed = db.get('any', ()) if permission in allowed or ALL in allowed: return True if interaction is None: return False if not interaction.participations: return False for participation in interaction.participations: token = participation.principal.getAuthenticationToken() allowed = db.get(token, ()) if permission not in allowed: return False return True В данном случае не требуется ничего специфического для класса взаимодействия, поэтомы мы можем использовать zope.security.simpleinteraction.Interaction. Посколько взаимодействие может иметь более чем одного принципала, мы проверяем все возможные полномочия. Это не является действительной необходимостью, поскольку мы создали взаимодействия только с одним активным принципалом. Здесь некоторый дополнительный код представлен с целью сократить текст, опустив определение базы полномочий которая определяет все полномочия для всех аутентифицированных групп и всех полномочий. Интеграция ~~~~~~~~~~ В данном месте мы уже имеем реализованную модель безопасности и нам необходимо интегрировать ее с нашей моделью симуляции. Мы выполняем это в три отдельных шага. Во-первых мы делаем так что агенты имеют доступ к песочницам обернутым в прокси безопасности. Это означает что любой доступ к песочницам и сервисам являются неявно защищенными нашей политикой безопасности. Вторым шагом мы хотим ассоциировать активного агента с контекстом безопасности, т.е. проверка агентского токена аутентификации по отношению к политике безопасности. Третим шагом устанавливаем нашу политику безопасности как политику по умолчанию для фреймворка безопасности Zope. Это означает возможность определить свою собственную политику и установить ее глобально. Интеграция доступа ~~~~~~~~~~~~~~~~~~ Представление по умолчанию интерфейсов управления взаимодействием определяет взаимодействия по потокам с функцией для доступа. Такая модель не применима для всех систем, так как ограничивает одним к одному активному взаимодействию на поток в каждый момент времени. Переопределение способов доступа к взаимодействиям несложно выполнить и оно упоминается для полноты описания. Перспективы ~~~~~~~~~~~ Важно помнить, что в этой статье описана небольшая часть всех возможностей при использовании фреймворка безопасности. Все взаимодействия основаны на интерфейсах, так что если Вам потребуется переопределить семантику в зависимости от комплекса приложений - достаточно реализовать интерфейс. Дополнительные возможности охватывают от ограничений интерпретаторов и динамической загрузки непроверенного кода до систем безопасности в не-Zope веб-приложениях. Включите воображение ;-). Zope перспектива ~~~~~~~~~~~~~~~~ У Zope3 программистов нет необходимости взаимодействовать с низким уровнем фреймворка безопасности. В Zope3 дополнительный пакет поверх низкого уровня фреймворка, источников аутентификации и контроллеров безопасности обрабатывается через zcml регистрацию. Т.е. всего что здесь описано, в реальности делать не нужно. Если конечно нет на то веских причин. Код ~~~ Полный код для примеров доступен - zope.security.examples. - sandbox.py - фреймворк агента - sandbox_security.py - реализация безопасности и связывание ее с фреймворком агента. Авторы ~~~~~~ - Kapil Thangavelu - Guido Wesdorp - Marius Gedminas Перевод ~~~~~~~ - Игорь Митин - Материал подготовлен к публикации КОМТЕТ

Вам также может помочь