Project KEEP：アクセス権限の動作確認

Domino REST API（Project KEEP）をアプリケーションに組み込むことを前提に、ACL と 読者フィールドの検証をしてみました。

検証に使用したアプリは、『Project KEEP 体験』シリーズで作成した郵便番号検索を再利用しました。利用する RestAPI は、Swagger UI の [data] セクションの /query を使用します。以下のリンクと同じ手順で、郵便番号を検索します。

Project KEEP 体験：#5）郵便番号検索 - Swagger UI によるテスト

ACL の検証

まずは、ACL により API のレスポンスがどのように変化するか調査します。RestAPI で接続するアプリケーションである『郵便番号マスタ』の ACL を変化させながら /query API をコールして、結果を確認します。

”管理者” から順に下げたところ、”読者” までは、正常にレスポンスが JSON で帰ってきました。

”投稿者” に設定すると、結果はエラーとなりました。レスポンスの JSON の message には ”Insufficient access, need READER (current level: DEPOSITOR)” と表示されており、エラーの原因がアクセス権限の不足であることがわかります。

次に、ACL を ”なし” に設定すると、エラーメッセージが ”Failed to open database: 操作を実行する権限がありません” と変化しました。

この結果より、認証で使用したユーザ ID に付与された ACL で動作していることが確認できました。また、エラーの原因は、JSON で確認できることがわかりました。

ちなみに、今回のテストは Swagger UI 上部の [Authorize] ボタンで Bearer を入力し認証したまま、Notes クライアントから ACL を変更しながら確認しました。それでも、即座に ACL が反映されましたので、Bearer が同じままでも、API コールのたびに ACL を判定していることがわかります。

読者フィールドの検証

続いて、セキュアなアプリでよく使用する ”読者フィールド” についてです。

今回は、郵便番号マスタの文書内に読者フィールドを作成し、”[Reader]” ロール保持者だけが文書を参照できるように設定しました。

まず、API をコールするユーザに ”[Reader]” ロールを保持させて実行したところ、問題なく検索できました。当たり前ですね...

次に、”[Reader]” ロールを外して検索したところ、次のような結果になりました。

エラーは出なかったのですが、レスポンスの JSON が空の配列となっていました。接続はできても、文書が見えないのですから、空の配列を返すという結果になったということですね。

まとめ

Domino REST API（Project KEEP）では、接続ユーザの権限でレスポンスを返すことがわかりました。ノーツのセキュリティモデルに沿っているのでとても理解しやすいですね。

今回のテストで、ACL 権限不足と読者権限がない場合の挙動が明確になりましたので、アプリケーションに組み込む際には、この結果に合わせたコーディングが必要ですね。