Access Control List

アクセス権のチェックには ACL（Access Control List）を使用します。

スコープおよび、Bucket、KiiObject、プッシュ通知のトピックのインスタンスに、それぞれ ACL が設定されます。現在ログインしているユーザーがそれらにアクセスするたびに、ACL を使ってアクセス権がチェックされ、実行の可否が決定されます。

ACL の構成

以下の図に示すように、Kii Cloud の ACL は、アクセス許可の集合から構成されるホワイトリストの形で表現されます。それぞれのアクセス許可は、サブジェクト（操作の主体）とアクション（実行する操作）で表現され、ACL エントリー と呼ばれます。

たとえば、阿田さんのユーザースコープの Bucket に井田さんが KiiObject を追加する権限を持っており、井田さんがこの Bucket に KiiObject を作成したとします。すると、KiiObject に対するアクセス権 に示すように、この KiiObject に対する読み取りと書き込みの権限が阿田さん（スコープオーナー）と井田さん（KiiObject 作成者）にデフォルトで与えられ、次の図に示すような ACL が設定されます。

ACL のアクション部に設定できる権限の種類は、オブジェクトの種類に応じて定められています。アクションの完全なリストは ACL エントリー を参照してください。

インスタンスと ACL の関係は、以下の図のとおりです。

インスタンスを作成したとき、Kii Cloud であらかじめ定められた ACL が自動的に割り当てられます。スコープはデータの所属先を表す概念であり、インスタンスとして作成することはありませんが、スコープの種類に応じてデフォルトの ACL が設定されています。

設定された ACL は、クライアント SDK や REST API が持つ ACL の変更機能を使ってカスタマイズすることができます。

アクセス権チェックの流れ

以下は Bucket に対するアクセス権をチェックするイメージです。

ユーザーがストレージにアクセスするとき、Bucket と KiiObject の 2 つのレベルでアクセス権がチェックされます。どちらのレベルでチェックされるかは操作により異なりますが、この 2 つを意識していないと意図した結果が得られないことがあります。

以下に操作の例を示します。

  • KiiObject の作成：これは Bucket に対する操作です。Bucket に対する KiiObject の作成権限のみがチェックされます。

  • KiiObject の検索と取得：これは Bucket 内の検索と KiiObject の読み取りを組み合わせた操作です。Bucket 内の検索権限がチェックされた後、得られた KiiObject に対する読み取り権限もチェックされます。

  • KiiObject の直接取得：これは空の KiiObject インスタンスを URI から直接生成し、リフレッシュ操作により内容を取得する操作です。KiiObject に対する読み取り権限だけがチェックされます。

注意事項

ACL について特に注意すべき点は以下のとおりです。

アクセス拒否エントリーはありません。

Kii Cloud にはアクセス拒否を実現する ACL エントリーはありません。そのため、特定のグループ中、特定のユーザーだけをアクセス不可にするような表現はできません。

なお、ACL を変更する API で拒否エントリーを設定できるように見えますが、実際に実行できる操作は許可エントリーの削除です。具体的には、KiiACLEntry クラスは KiiSubject、KiiAction、grant(bool) で構成されます。この grant を false に設定して既存の ACL エントリーを更新すると、そのエントリーが削除されます。たとえば、「宇田さんによる読み取り」が設定されている ACL からこの許可を削除したいときは、「宇田さん、読み取り、grant=false」を指定して既存の ACL エントリーを上書きします。

スコープオーナーや作成者の ACL エントリーは削除できません。

アプリケーションの管理者や ACL の操作が可能なユーザーであっても、デフォルトで設定されている ACL エントリーのうち、スコープオーナー（スコープを所有する、グループオーナー、ユーザー、Thing）や Bucket/KiiObject/トピック作成者の ACL エントリーは削除できません。たとえば、グループスコープの Bucket の ACL から、Bucket 作成者に QUERY_OBJECTS_IN_BUCKET アクションを許可する ACL エントリーは削除できません。

削除できない ACL エントリーを以下に示します。

アプリケーションスコープ：

  • KiiObject 作成者の READ_EXISTING_OBJECT、WRITE_EXISTING_OBJECT
  • トピック作成者の SUBSCRIBE_TO_TOPIC、SEND_MESSAGE_TO_TOPIC

グループ/ユーザー/Thing スコープ：

  • スコープオーナーの CREATE_NEW_BUCKET、CREATE_NEW_TOPIC
  • Bucket 作成者の QUERY_OBJECTS_IN_BUCKET、CREATE_OBJECTS_IN_BUCKET、READ_OBJECTS_IN_BUCKET、DROP_BUCKET_WITH_ALL_CONTENT
  • スコープオーナーと KiiObject 作成者の READ_EXISTING_OBJECT、WRITE_EXISTING_OBJECT
  • スコープオーナーとトピック作成者の SUBSCRIBE_TO_TOPIC、SEND_MESSAGE_TO_TOPIC

ACL に順序付けはありません。

Kii Cloud の ACL はホワイトリストであるため、エントリーの順序は処理に影響を与えません。

重複する ACL エントリーは追加できません。

重複するエントリーを追加するなど、不適切な ACL エントリーを作成するとエラーとなります。

複数の ACL エントリーを変更するときは失敗時の動作に注意が必要です。

Android、iOS、JavaScript の SDK では、複数の ACL エントリーを同時に変更するときに注意が必要です（REST ではこの現象は発生しません）。

これらの SDK から複数の ACL エントリーを書き換えるとき、変更処理の実行メソッド（save メソッド）の内部でネットワークアクセスが複数回発生し、順番に ACL エントリーが書き換えられます。この処理が途中でエラーになった場合や、処理中にプロセスが終了した場合、先行する一部の ACL エントリーだけが書き換わることがあります。モバイルアプリでは、重要度に応じて再試行などの対策を検討します。トランザクション もご覧ください。

なお、クライアント SDK によっては、エラーの発生時、成功した ACL エントリーと失敗した ACL エントリーを一覧として取得することができます。