Создание роли на основе разрешений MarkLogic - PullRequest
0 голосов
/ 08 ноября 2019

MarkLogic 9.0.8.2

Мы разработали API для получения и установки данных в MarkLogic. Все данные хранятся в формате XML в MarkLogic

Теперь мы хотим предоставить конечную точку API внешнейпользователи с операциями ниже

  • READ
  • INSERT
  • UPDATE
  • NODE-UPDATE
  • EXECUTE
  • ADMIN

Итак, мы хотим создать различные учетные данные пользователя на основе разрешений, таких как ReadOnly, ExecuteOnly.

Какие все роли и разрешения нам нужно выбрать, чтобы убедиться, что они могут выполнять свои функцииразрешено?

1 Ответ

0 голосов
/ 15 ноября 2019

Примечание: права доступа к документу, права доступа к функциям. В частности, разрешение на выполнение относится только к доступу к модулю, а не к доступу к документу.

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

Начните с 4 ролей без самих свойств. Поместите «read», «insert», «update» и «node-update» в имена.

Создайте пятую роль с именем «defaults» в имени и предоставьте ей разрешения по умолчанию для указанных четырех ролей. где возможность совпадает с именем роли (например, «чтение» для роли чтения и т. д.).

Затем создайте роли более высокого уровня для абстрактных понятий, таких как читатель, писатель и сопровождающий. Читатель наследует только роль чтения, писатель наследует читателя, вставку, обновление и значения по умолчанию. Сопровождающий наследует писателя. Удаление - это особый вид обновления, который не различим. Node-update - это подмножество обновлений. Я не сталкивался со случаем использования, когда я хотел разрешить обновление узла, но не полное обновление.

Разрешения на выполнение здесь не имеют смысла, поскольку это относится только к модулям, а не к документам. Права на выполнение используются для разрешения использования определенных функций (например, sem: sparql, xdmp: http-get и т. Д.). Примените их соответствующим образом к ролям читателя и автора.

Избегайте применения более опасных привилегий выполнения, таких как xdmp: spawn и xdmp: eval, к любой из вышеперечисленных ролей. Если вы столкнулись с необходимостью, то создайте роль, которую вы используете для Amps (вы можете указать «усилители» в названии), и убедитесь, что вы используете эту роль только для Amps, и никогда не назначаете ее для ролей или пользователей. .

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

HTH!

...