Не удается создать пользовательские разрешения для ограничения контента

Я изо всех сил пытаюсь правильно настроить права/привилегии/роли пользователя, чтобы получить нужное мне поведение.

Я использую MarkLogic 8 и Roxy для создания и развертывания приложения.

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

Я видел этот полезный блог и обсуждение проблемы 303 github, но до сих пор не могу понять это правильно.

Роль пользователя приложения Roxy по умолчанию:

<role>
  <role-name>${app-role}</role-name>
  <description>A role for users of the ${app-name} application</description>
  <role-names>
  </role-names>
  <permissions>
    <permission>
      <capability>execute</capability>
      <role-name>${app-role}</role-name>
    </permission>
    <permission>
      <capability>update</capability>
      <role-name>${app-role}</role-name>
    </permission>
    <permission>
      <capability>insert</capability>
      <role-name>${app-role}</role-name>
    </permission>
    <permission>
      <capability>read</capability>
      <role-name>${app-role}</role-name>
    </permission>
  </permissions>
  <collections>
  </collections>
  <privileges>
    <privilege>
      <privilege-name>xdmp:value</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:add-response-header</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:invoke</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:with-namespaces</privilege-name>
    </privilege>
  </privileges>
</role>

Моя пользовательская роль:

<role>
  <role-name>sccss-user</role-name>
  <description>sccss default role</description>
  <role-names>
    <!-- TODO test which roles we really need -->
    <!--
    <role-name>alert-user</role-name>    
    <role-name>alert-internal</role-name> 
    <role-name>rest-admin</role-name> 
    <role-name>rest-writer-internal</role-name>
    <role-name>rest-reader</role-name> 
    <role-name>network-access</role-name>
    <role-name>qconsole-user</role-name>
    -->
    <!-- cluey app role for rest api access TODO replace with dedicated api user and role 

    <role-name>${app-role}</role-name>
    -->

  </role-names>
  <permissions>
  </permissions>
  <collections>
  </collections>
  <privileges>
    <!-- HK -->
    <!--
    <privilege>
      <privilege-name>any-uri</privilege-name>
    </privilege>
    -->
    <privilege>
      <privilege-name>devices-uri</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>any-collection</privilege-name>
    </privilege>
    <!-- to make this role have acces to the REST API-->
    <privilege>
      <privilege-name>rest-reader</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>rest-writer</privilege-name>
    </privilege>
    <!-- TODO test this
    <privilege>
      <privilege-name>xdmp:value</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:add-response-header</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:invoke</privilege-name>
    </privilege>
    <privilege>
      <privilege-name>xdmp:with-namespaces</privilege-name>
    </privilege>
  </privileges>
  -->
</role>

Я тестировал и пробовал то, что описано в блоге выше, но с этими настройками я не получаю доступа ни к одному документу, по-видимому, без доступа к остальным расширениям. Если я даю своим пользователям {app-role}, это создает проблему, заключающуюся в том, что пользователи могут видеть личный контент других пользователей... потому что у всех пользователей есть роль "остального-читателя"... Поэтому мне нужно ограничить значение по умолчанию- роль приложения, чтобы не использовать роль чтения остальных и использовать привилегии чтения остальных, но не могу заставить ее работать...

Один из вариантов, который я рассматриваю, — использовать разрешения document-insert() для ограниченного контента, но это должно быть возможно с правильными ролями и привилегиями, если я смогу правильно настроить его, верно?

ДОБАВЛЕНИЕ

В ответ на ответ Grtjn: спасибо за ваши комментарии, я думаю, что озадачен ролями REST. Если я посмотрю на роли по умолчанию в приложении roxy на git они выглядят пустыми, но когда я устанавливаю тип приложения roxy в качестве приложения REST, все становится сложнее. Основная путаница заключается в том, какие роли и привилегии мне нужны, чтобы вторая (независимая) роль могла использовать конечную точку REST? Каковы привилегии xdmp: (значение, добавление-ответа-заголовка, вызовы и т. д.) и для чего они нужны? В моем примере, чтобы пользователь мог получить доступ к REST API, ему нужны следующие роли:

      <role-name>${app-role}</role-name>
      <!-- we need this to amp internal privileges-->
      <role-name>alert-user</role-name>    
      <role-name>alert-internal</role-name> 
      <role-name>rest-admin-internal</role-name> 

А затем мы приступаем к обсуждению, должно ли чтение остальных быть привилегией или ролью?

Итак, более конкретный вопрос:

Каков минимальный набор ролей/привилегий, который мне потребуется для доступа к конечной точке REST, созданной приложением типа roxy rest?


person Hugo Koopmans    schedule 01.10.2016    source источник


Ответы (1)


Я бы рекомендовал использовать следующий подход здесь:

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

Затем убедитесь, что расширения REST и все остальное, что не развернуто Roxy напрямую, получают разрешение на чтение и выполнение документа. Подумайте о триггерах и оповещениях, созданных с помощью пользовательского кода, sql-представлений или схем, не загруженных схемами развертывания и т. д. Функция change_permissions, которую мы используем в slush-marklogic-node, может служить примером того, как с этим справиться: https://github.com/marklogic/slush-marklogic-node/pull/298/files#diff-a529d1d70bd21866e1d12eda3a99f7b6R96

После этого создайте выделенную роль для каждой части контента, к которой необходимо предоставить доступ отдельно. Если вам нужно, чтобы набор документов был доступен только одному пользователю, вам потребуется конкретная роль пользователя. Если у вас также есть набор документов, доступный только участникам проекта, вам также нужна роль для конкретного проекта. Если вам нужно также различать чтение/запись, сделайте две роли для каждого (две роли пользователя, две роли проекта). Эти роли не будут иметь привилегий и не должны наследовать роли (за исключением, возможно, записи, наследующей соответствующую роль чтения).

После того, как у вас есть роли чтения/записи, вы можете начать думать о том, как правильно применять их для разрешений документов при загрузке. При таком уровне сложности вы, возможно, захотите избежать разрешений по умолчанию и явно выбрать разрешения для документов. xdmp:document-insert, MLCP и /v1/documents требуют явных разрешений на доступ к документам, поэтому у вас должен быть разумный контроль над ними.

ДОБАВЛЕНИЕ

Обратите внимание на готовый файл ml-config Roxy. Он не настроен должным образом для приложений типа REST. Именно поэтому генератор slush-marklogic-node исправляет мл-конфиг: https://github.com/marklogic/slush-marklogic-node/blob/master/slushfile.js#L346

Минимум, чтобы иметь доступ на чтение к REST API, — это привилегия для чтения остальных, а для доступа к обновлению к REST API — это привилегия для записи на отдых. Расширения REST запускаются из базы данных модулей, а не из файловой системы, поэтому для этого вам дополнительно нужен доступ к модулю. Упомянутая выше функция change_permissions исправляет это за вас.

В любом случае, мой общий совет — использовать роль приложения для выполнения приложения, как упоминалось ранее, и другие роли для доступа к данным. Любой пользователь, который хочет использовать приложение, должен наследовать роль приложения, а также некоторые другие роли, чтобы обеспечить соответствующий объем доступа к данным.

ХТХ!

person grtjn    schedule 03.10.2016
comment
привет Grtjn, я обновил свой вопрос, чтобы быть более конкретным ... надеюсь, вы можете поделиться своим мнением по этому поводу? Спасибо - person Hugo Koopmans; 04.10.2016