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

Question

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

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

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

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

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

Роль пользователя приложения 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}, то возникает проблема с тем, что пользователи могут видеть частный контент других пользователей... потому что все пользователи имеют роль 'rest-reader'... Так что мне нужно ограничить default- роль приложения, чтобы не использовать роль rest-reader и использовать привилегии rest-reader, но не могу заставить его работать...

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

Сложение

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

      <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?

1

rest marklogic marklogic-8 roxy

Источник

user1707429 01 окт '16 в 12:25

1 ответ

Другие вопросы по тегам rest marklogic marklogic-8 roxy

user918496 03 окт '16 в 07:17 2016-10-03 07:17 · Answer 1 · 2016-10-03 07:17

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

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

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

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

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

Сложение

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

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

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

НТН!