1

必要な動作を得るために、ユーザーのアクセス許可/特権/ロールを正しく設定するのに苦労しています。

MarkLogic 8 と Roxy を使用して、アプリケーションを作成および展開しています。

このアプリケーションには、個々のユーザーに制限する必要があるコンテンツを持つさまざまなユーザーがいます。しかし、彼らは一緒に協力する必要があるプロジェクトにも参加しています。

この役立つブログgithub issue 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」ロールを持っているためです...したがって、デフォルトを制限する必要があります-アプリの役割は、rest-reader ロールを使用せず、rest-reader 特権を使用しますが、機能させることはできません...

私が検討しているオプションの 1 つはdocument-insert()、制限されたコンテンツにパーミッションを使用することですが、適切に設定できれば、適切なロールと特権でこれが可能になるはずですよね?

添加

Grtjn の回答 : thx 4 のコメントに応えて、私は REST の役割に困惑していると思います。git で roxy アプリのデフォルト ロールを見ると、それらは空に見えますが、roxy アプリの種類を REST アプリに設定すると、状況がより複雑になるようです。主な混乱は、REST エンドポイントを使用できるようにするために、2 番目の (独立した) ロールに必要なロールと特権は何ですか? xdmp:(value、add-response-header、invokes など) 権限は正確に何をし、何のために必要ですか? ユーザーが 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> 

そして、残りのリーダーが特権または役割であるべきかどうかについての議論に入ります。

より具体的な質問:

roxy レスト タイプ アプリケーションによって作成された REST エンドポイントにアクセスするために必要な最小限のロール/権限セットは何ですか?

4

1 に答える 1

1

ここでは、次のアプローチを取ることをお勧めします。

最初のコンテンツ アクセスではなく、アプリケーションの実行に app-role を使用します。そのため、そのロールからデフォルトのアクセス許可を削除し、rest-reader/rest-writer 特権と、MLCP などを実行するためのいくつかの特権を付与します。

次に、REST 拡張機能、および Roxy によって直接デプロイされていないその他のものが、ドキュメントの読み取りと実行のアクセス許可を取得していることを確認します。カスタム コードで作成されたトリガーとアラート、SQL ビュー、またはデプロイ スキーマが読み込まれていないスキーマなどについて考えてみてください。 com/marklogic/slush-marklogic-node/pull/298/files#diff-a529d1d70bd21866e1d12eda3a99f7b6R96

個別にアクセス権を付与する必要があるコンテンツの各部分に専用のロールを作成します。1 人のユーザーだけが一連のドキュメントにアクセスできるようにする必要がある場合は、ユーザー固有の役割が必要になります。プロジェクト メンバーのみがアクセスできる一連のドキュメントもある場合は、プロジェクト固有の役割も必要です。読み取り/書き込みも区別する必要がある場合は、それぞれに 2 つのロール (2 つのユーザー、2 つのプロジェクト ロール) を作成します。これらのロールには特権がなく、ロールを継承すべきではありません (対応する読み取りロールを継承する書き込みを除く)。

読み取り/書き込みの役割を取得したら、取り込み時にドキュメントのアクセス許可にそれらを正しく適用する方法について考え始めることができます。このレベルの複雑さでは、既定のアクセス許可を避けて、ドキュメントのアクセス許可を明示的に選択することをお勧めします。xdmp:document-insert、MLCP、および /v1/documents はすべて明示的なドキュメント アクセス許可を取得するため、これらを適切に制御する必要があります。

添加

Roxy のすぐに使える ml-config ファイルに関する注意事項。REST タイプのアプリケーション用に適切に調整されていません。そのため、slush-marklogic-node ジェネレーターは ml-config にパッチを適用します: 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 関数はそれを修正します。

とにかく、私の一般的なアドバイスは、前述のようにアプリの実行には app-role を使用し、データ アクセスには他のロールを使用することです。アプリを使用するすべてのユーザーは、適切な量のデータ アクセスを提供するために、app-role と他のいくつかのロールを継承する必要があります。

チッ!

于 2016-10-03T07:17:43.940 に答える