fess-ds-sharepointプラグインを利用したクロール時のroleフィールドについて

Japanese:Fess
1

ご多用のところ恐れ入ります。下記の通り質問させてください。
※不足情報ある場合は大変お手数ですがコメントいただければ幸いです。

■前提

  • Fess 14.8.0
  • fess-ds-sharepointプラグイン 14.8.0
  • ElasticSearch 8.6.2
  • [こちら](簡単導入! OSS全文検索サーバFess入門(35) SharePoint Serverのクロール | TECH+（テックプラス） (mynavi.jp))を参考にしてクロール設定などは登録した
  • クロール先のSharePoint ドキュメントについて
    • 「TEST」フォルダを１つ作成
      • 「TEST」フォルダに対しては「test」Sharepointグループがアクセス許可レベル、フルコントロールで付与されており、配下のドキュメントにはデフォルトで「test」のアクセス許可が付与される。
    • 「TEST」フォルダの中に、Aドキュメント、Bドキュメント、Cドキュメントの3件作成
      • Aドキュメントに対し、「アクセス許可の管理」によるアクセス権は変更しない
        • フォルダのデフォルトの権限、ここでは「test」グループの権限のみが付与されている
      • Bドキュメントに対し、「アクセス許可の管理」により、「test」グループに所属していない、「b」ユーザーのアクセス権限を付与する。
        • フォルダのデフォルトの権限「test」グループについては付与されてる状態のまま変更しない。
      • Cドキュメントに対し、「アクセス許可の管理」により、「test」グループに所属していない、「c」ユーザーのアクセス権限を付与する。
        • フォルダのデフォルトの権限「test」グループについては付与されてる状態のまま変更しない。

■質問内容
前提のもとクロールし、fess.xxxx（日付）インデックスから結果を確認すると、roleフィールドの値が下記のように期待するroleの値と、実際の値に差異がありました。「アクセス許可の管理」を編集していないドキュメントのroleフィールドには、サイトへのアクセス許可レベルが「制限付きアクセス」のユーザー情報（ここでは「b」と「c」）であっても、サイト内に何かしら紐付くアクセス権は全てroleに登録されているように見えます。
こちらは仕様でしょうか？また、設定などで期待する値にすることは可能でしょうか？

  • 期待するrole
    • Aドキュメント：「test」グループ
    • Bドキュメント：「test」グループ、「b」ユーザー
    • Cドキュメント：「test」グループ、「c」ユーザー
  • 実際のrole
    • Aドキュメント：「test」グループ、「b」ユーザー、「c」ユーザー
    • Bドキュメント：「test」グループ、「b」ユーザー
    • Cドキュメント：「test」グループ、「c」ユーザー

■補足情報

  • ShrePoint側の設定で回避できたり、APIの仕様である場合は申し訳ありません。
  • 実際には、“1system”,“Rguest”,といった値もroleに登録されていますが、本件には関係ないと思うため省略
  • 上記の結果がえられた後に、Aドキュメントに対し、SharePoint上で「b」ユーザーのアクセス権を付与し、すぐ「b」ユーザーのアクセス許可を無効にする。その後クロールすると、期待するroleになります。
    • このことから何かしらアクセス許可の編集が行われているドキュメントと、そうでないデフォルトのままのドキュメントをどこかで判断しているのだと想像しますが、それがfess-ds-sharepointの仕様か、使用しているAPI側の仕様かわからずうかがっています。
2

実装的にはここらへんの話かなと思います。

3

ご回答ありがとうございます。
頂いた情報を元に、Sharepointの仕様なども含めて調査を行いました。
時間がかかり返信遅れ申し訳ありませんでした。
調査内容が今後のバージョンアップの一助になればと思い共有させていただきます。

調査結果

SharePoint Online

  • SharePoint Online上のドキュメントに個別でアクセス許可を追加すると、親Webサイトにゲストロール(＝制限付きアクセス)権限が追加されてしまう。
  • 「ゲストロール(=制限付きアクセス)」については、下記の通り「詳細に設定された権限と組み合わせて使用して、サイト全体へのユーザーのアクセスを許可せずに、そのユーザーが特定のリスト、ドキュメントライブラリ、フォルダー、リストアイテム、またはドキュメントにアクセスできるようにする」ために便宜的に設定されるロールで、「制限付きアクセス」の権限が設定されているドキュメント自体にはアクセス権限はない。
  • 新規作成したドキュメント（「アクセス許可の管理」を一度もしていないドキュメント）は、親要素の権限を継承する。
  • あるドキュメントに個別で特定のユーザー／グループの権限を付与すると、そのユーザー／グループに対する「制限付きアクセス」の権限がサイト全体やそれを継承したドキュメントにも付与されるが、実際にアクセスできるのは個別で権限を追加したドキュメントのみ

fess-ds-sharepointプラグイン

  • GetListItemRole.javaのbuildRoleAssignmentsUrlにて権限情報取得時に、アクセス許可の管理をしていない（権限がデフォルト状態の）ドキュメントには「アクセス許可レベル」が「制限付きアクセス」のデータも含まれるため、それも一緒に取得される。

結論

  • 前述の内容より、当初確認させていただいた『「アクセス許可の管理」を編集していないドキュメントのroleフィールドには、サイトへのアクセス許可レベルが「制限付きアクセス」のユーザー情報（ここでは「b」と「c」）であっても、サイト内に何かしら紐付くアクセス権は全てroleに登録されているように見える』という事象が発生したと思われます

追加調査

  • SharePoint Onlineのブラウザ上で一度もアクセス許可の管理をしていないドキュメントはデフォルトの権限セット（RoleDefinitionBindings）が付与される。

    • RoleDefinitionBindingsオブジェクトについて
    • デフォルトの権限セット（RoleDefinitionBindings）には一意の先祖Webサイトまで、すべての親フォルダー、リスト、Webサイトに対する権限情報が含まれているので、「制限付きアクセス」のユーザーも含め取得される。
    • 一度、アクセス許可の管理で任意のユーザーのアクセスを許可すると、新しい権限セット（RoleDefinitionBindings）が追加され、そこにはドキュメントに紐づく権限情報がある。
    • なので、下記のAPIで特定のItemのRoleDefinitionBindingsを取得すると、アクセス許可の管理をしていない権限がデフォルト状態のドキュメントには1件、一度でもアクセス許可をの管理を実施したドキュメントには複数件のRoleDefinitionBindingsが返却される。
    /_api/Web/Lists(guid'xxxx')/Items(xxxx)/RoleAssignments?$expand=RoleDefinitionBindings

  • GetListItemRole.javaのbuildRoleAssignmentsUrlを、このあたりで実行する際に、APIのURLに?$expand=RoleDefinitionBindingsを付与すると。RoleTypeKind(アクセス許可レベル)も一緒に取得することができるので、それが期待しない値(0や1など値の詳細は公式のこちら)の場合は、除外するようにすれば以降の処理で、期待する権限をRoleフィールドに追加することができそうだと思いました。

  • 補足：

    • いくつかのweb記事を見る限り、例えば下記のようなAPIを実行できれば、そもそものAPIレスポンスの中から、RoleTypeKindを限定することができそうでしたが手元の環境ではうまく実行できませんでした。
    /_api/Web/Lists(guid'xxxx')/Items(xxxx)/RoleAssignments?$expand=RoleDefinitionBindings&$filter=RoleDefinitionBindings/RoleTypeKind ne 1
2 Likes