2013-05-29 3 views
2

Для среды CQ5, над которой я работаю, у нас есть ферма серверов издателей. Некоторое содержимое на этих серверах ограничено, поэтому только контент, принадлежащий определенным группам, может видеть контент. Я хотел бы сценарий настройки разрешений для папок (узлов), которые должны быть защищены, поэтому мне не нужно вручную повторять шаги по применению безопасности с помощью редактора управления доступом Content Explorer (This Adobe documentation имеет инструкции для этого вручную через редактор управления доступом). Сценарий заключается в том, что иногда для создания защищенных страниц необходимо создать новые папки, и мы хотим применить разрешения к папкам до активации любого содержимого в этих папках.Как я могу автоматизировать применение разрешений для узла JCR?

Поскольку среда имеет несколько издателей, она повторяется, работает вручную и подвержена ошибкам, чтобы открыть Content Explorer и установить разрешения для каждого из них. Я бы хотел, чтобы это удалось автоматизировать, чтобы я мог выкачать разрешения на все серверы через скрипт - возможно, с помощью команды curl или какого-либо другого механизма (возможно, пакета?), Который может быть автоматизирован.

Я нашел Sling jackrabbit-accessmanager bundle, который, похоже, облегчит автоматизацию этого, но похоже, что он открывает дыру в безопасности. Если я поставлю этот пакет на своих издателях, мне кажется, что я предоставляю интерфейс REST, чтобы кто-либо мог изменять разрешения и предоставлять доступ к папкам/узлам, которые должны быть защищены, или добавить ограничения безопасности для узлов, которые не должны иметь ни одного.

Как я могу автоматизировать создание/изменение разрешений узлов через скрипт - и сделать это таким образом, чтобы администратор мог применять изменения разрешений?

+0

Права на страницы в 5.5 больше не копируются от автора к издателю (см. Http://helpx.adobe.com/cq/kb/PagePermissionsNotReplicatedWithUser.html и http://forums.adobe.com/message/5260261) – Shawn

ответ

2

Я нашел одну альтернативу, которую я раньше не рассматривал: используя службу настройки ACL Day CQ. Он упоминается в http://dev.day.com/docs/en/cq/5-5/developing/security_model_changes.html.

AclSetupService позволяет добавлять разрешения одному пути или заданному пользователю/группе. Это будет применяться при каждом перезапуске CQ, чтобы гарантировать определенное разрешение в CQ. Например, «allow; inherit; everyone; /» не позволяет каждому получить доступ к CQ (т. Е. Заставляет всех пользователей сначала войти в систему). Как указано в описании AclSetupService, вам понадобится следующий шаблон для каждой записи:

(«allow» | «deny») »; (привилегии | "inherit") ";" главный ";" путь

  1. Выберите «разрешить» или «отклонить» для первой части.
  2. Далее введите одну из привилегий ниже или установите для наследования разрешение от предка.
  3. Затем введите один пользователь/группу.
  4. Наконец, введите один путь для применения разрешения.

Использование этого заменит набор разрешений в репозитории при перезагрузке CQ. Они могут быть написаны сценарием с использованием процесса, описанного here и here.

Привилегии могут быть:
JCR: чтение
респ: написать
JCR: все
CRX: реплицировать
имп: SetComplete
JCR: addChildNodes
JCR: lifecycleManagement
JCR: lockManagement
jcr: modifyAccessControl
jcr: modifyProperties
jcr: namespaceManagement
JCR: nodeTypeDefinitionManagement
JCR: nodeTypeManagement
JCR: readAccessControl
JCR: removeChildNodes
JCR: RemoveNode
JCR: retentionManagement
JCR: versionManagement
JCR: workspaceManagement
JCR: написать
репутацию: privilegeManagement

0

Если вы хотите использовать пакет Sling jackrabbit-accessmanager в экземпляре публикации, это возможно. Вы хотите убедиться, что ваш диспетчер, который находится перед экземпляром публикации, не разрешает запросы на разрешение (/.modifyAce., .deleteAce. И т. Д.), А экземпляры публикации могут быть доступны только изнутри вашей сети. Стандартная практика - отклонять все запросы диспетчера и указать, что разрешено.

Есть ли причина, по которой вы не просто реплицируете разрешения при активации папки? Должен быть узел rep: policy под защищенной папкой, которая реплицируется.

+0

К сожалению, доступ к любому, кто может обойти диспетчера и ударить издателя напрямую, по-прежнему недостаточно безопасен, чтобы передать наше требование безопасности (большая компания ... слишком много людей все равно будут иметь доступ). Простой способ активации - это, безусловно, тот, который мы рассмотрели, но это потребует некоторых изменений в структуре безопасности. Тем не менее, это действительно лучший маршрут. – Shawn

2

Этот инструмент позволяет управлять разрешениями в центре sed, они также могут быть установлены автоматически во время развертывания: https://github.com/Netcentric/accesscontroltool

Что касается прав доступа к новым папкам, решение правильно устанавливает разрешение на их родительскую папку. CQ/AEM автоматически применяет те же разрешения для всех детей, если другое правило не нарушает наследование.

Смежные вопросы