ロールと権限

服屋のショッピングモール Space に同僚 minji.kim@example.com を割り当てたと考えてみてください。同僚には商品を登録したり修正したりする作業は任せたいけれど、商品を削除したり外部に公開したりする作業まで任せるのは慎重になります。このように「ある Space の中でメンバーが何をできて何はできないか」を定めておく権限のまとまりが SpaceRole です。

SpaceRole は、メンバー一人ひとりに権限を個別に割り当てる代わりに、権限のまとまりをあらかじめ作っておき、それをメンバーに付与する方式です。たとえば「商品を読んで修正だけできる」ロールを一度作っておけば、商品登録を任せたい同僚たちにそのロールを一つ付けるだけで済みます。メンバーが増えても、権限を毎回最初から定める必要はありません。

このページでは、SpaceRole が何であり、どんな権限を含むのかをまず見たうえで、服屋の Space に「商品登録担当」ロールを実際に作ってみます。

Space のロールは Organization のロールと異なります

WEEGLOO には権限を定める場所が二つあります。混同しやすいので、まず境界を引いておきます。

  • Organization のロール(OwnerAdminMember)は、会社全体での等級です。メンバーを招待したり Space を新しく作ったりするように、Organization 全体にまたがる作業を誰ができるかを定めます。
  • SpaceRole は、特定の一つの Space の中での権限です。その作業空間に入って商品を作ったり、修正したり、公開したりするように、コンテンツを扱う作業をメンバーがどこまでできるかを定めます。

同じ同僚でも、Space ごとに異なる SpaceRole を与えられます。ショッピングモールの Space では商品を修正までできるようにし、社内のお知らせ用の Space では読むだけにする、といった具合です。このページは SpaceRole だけを扱います。Organization のロールやメンバーの招待・割り当ては 組織とスペース で扱います。

ロールに含まれるもの: 何に、どんな操作を

一つの SpaceRole には「どんな対象に対して、どんな操作を、許可するのか拒否するのか」が含まれます。

まず、権限を定める対象は四つあります。このうち次の三つの対象は同じ操作のまとまりを共有し、四つ目の Script は操作が異なるため後ろで別に扱います。

  • Content Type: 商品やお知らせのようなひな形
  • Content: そのひな形で作った商品一つひとつ
  • Media: アップロードした写真や動画のようなファイル

対象ごとに許可または拒否できる操作は次のとおりです。

操作は画面に英語で表示されます。各操作の意味は次のとおりです。

操作(画面表記)何をするか
Read一覧と内容を見ます
Create新しく作ります
Editすでにあるものを直して保存します
Delete削除します
Publish外部に公開(配信)されるよう発行します
Unpublish発行を取り下げて外部公開を止めます
Archive保管状態に移します
Unarchive保管から戻します
All actions上のすべての操作を一度に許可します

服屋の例で言うと、「商品登録担当」ロールには Content(商品)に対して Read・Create・Edit は許可し、Delete・Publish は入れない、というように操作を選んで含めます。そうすると同僚は商品を作ったり直したりはできますが、削除したり外部に公開したりはできません。

Publish が何であり、発行すると外部にどう公開(配信)されるのかは、状態と発行 で詳しく扱います。

許可と拒否

ロールの画面には 許可 リストと 拒否 リストが別々にあります。できるようにしたい操作を 許可 リストに一行ずつ入れる方式です。重要な点は、許可リストに入れなかった操作は自動的に拒否される ということです。ですから、同僚に与えたい操作だけを許可に入れれば、残りは別途ふさがなくてもふさがれます。

拒否 リストは、「広く許可しておきつつ、特定の部分だけ例外としてふさぎたいとき」に使う安全装置です。一つの操作が許可と拒否に同時にかかると、拒否が常に優先されます

特定の種類・特定の人へ範囲を狭める

操作を許可するとき、その許可を一つの種類や特定の条件だけに狭めることができます。たとえば次のような絞り込みが可能です。

  • 一つの種類だけに: 「商品」Content Type にだけ適用し、ほかの Content Type には適用しません。
  • 自分が作ったものだけに: そのメンバーが自分で作った Content だけを扱えるようにし、他人が作ったものには手を出せないようにします。
  • 特定の Tag が付いたものだけに: 決められた Tag が付いた ContentMedia にだけ適用します。

範囲を別途狭めなければ、その操作は対象の全体に適用されます。たとえば Content の読み取りを狭めずに許可するとすべての Content を読むことができ、「商品」Content Type に狭めると商品だけを読むことができます。

Tag が何かは Tag で扱います。

Script の実行・管理の権限

SpaceRole は、前の三つの対象のほかに Script に対する権限も含みます。Script は、フロントエンドが呼び出す、サーバーコードなしで作るバックエンドのエンドポイントです(Script を参照)。ContentMedia にはない Execute(実行)という操作がここにあります。

  • Execute: その Script を実行(呼び出し)できるようにします。フロントエンドや登録済みの会員が Script を呼ぶには、この権限が必要です。
  • ReadCreateEditDelete: Script を照会し、作り、直し、削除する管理権限です。

「自分が作った Script だけ」を扱うように、作成者を基準にして狭めることができます。発行の操作はありません。Script は発行する資源ではないからです。製品に登録した会員(ServiceUser)には、ふつう Execute だけを開けておきます。Script を作ったり直したりする作成は、コンテンツスタジオの利用者が担うからです。

Role 編集画面の Script 権限タブ。許可リストに操作 Execute・範囲「任意のScripts」・作成者「任意のユーザー」のルールを一行入れた状態

権限ルールの正確な形式は、SpaceRoleServiceUserRole の API リファレンスで扱います。

Space の設定を変えられるかどうかもロールが定めます

ここまではコンテンツと Script を扱う権限でした。ロールには性格の異なる一覧がもう一つ含まれます。Space の設定を変えられるかどうかです。

服屋の例に戻ると、同僚に商品の登録は任せたいけれど、Locale を新しく追加したり、外部のサイトが使うトークンを発行したりする作業まで任せたいとは思わないはずです。こうした Space の設定作業を誰ができるかが、この一覧で定まります。

前の権限と違って、この一覧には操作も範囲の絞り込みもありません。項目をオンにするとその設定を扱えるようになり、オンにしなければ扱えません。 ロールを作る画面と直す画面の Permissions タブでオンとオフを切り替えます。一番上の すべての管理Permission をオンにすると下の項目が一度にオンになり、項目を一つずつすべてオンにしてもこのトグルはオンとして表示されます。 オンにできる項目は次のとおりです。

項目オンにするとできるようになること
Space情報の管理Space の名前と説明を直します
Membershipの管理この Space にメンバーを入れたり外したりし、メンバーのロールを変えます
Roleの管理このページで作ったようにロールを作ったり直したりします
Delivery Access Tokenの管理読み取り専用のトークンを発行して管理します
Space Access Tokenの管理読み書きするトークンを発行して管理します
Localeの管理言語を追加したり、基準の言語を変えたりします
Email Accountの管理メールを送るときに使う送信元アカウントを登録します
Appの管理マーケットからアプリを取り込んでインストールします
Tagの管理Tag を作ったり直したり削除したりします
Web Hostingの管理サイトを公開してドメインを接続します
ServiceLoginの管理製品に登録する会員のログインと会員の権限を設定します
Webhookの管理Webhook を作って呼び出し履歴を見ます
Schedulerの管理Scheduler を作って実行履歴を見ます
モニタリングの閲覧この Space が使った容量とトラフィックを見ます

トークンが二種類に分かれていることに注意してください。読み取り専用の Delivery Access Token だけを発行できるようにし、読み書きする Space Access Token は発行できないようにふさぐことができます。公開サイトに入れる読み取り用のトークンは同僚が自分で発行できるようにしておきつつ、書き込みまでできるトークンは管理者だけが作れるようにしたいとき、このように分けて与えます。

Schedulerの管理 はこの項目だけで終わりません。Scheduler を作ったり直したりするときは、それが実行する ScriptExecute 権限も一緒に必要です(誰の権限で実行されるか を参照)。

どの項目もオンにしなければ、そのロールはコンテンツだけを扱うロールになります。後ろで作ってみる「商品登録担当」ロールがその場合です。商品は登録したり直したりできますが、Space の設定は一つも触れません。

Role 作成画面の Permissions タブ。一番上のすべての管理Permission トグルがオフで、その下の 14 項目もすべてオフの状態です

Space を作るとついてくる Administrator ロール

Space を新しく作ると、Administrator というロールが自動的に一つ一緒に生成されます。このロールは、その Space の中のすべてを扱える最高権限のロールです。Space を作った人は、この Administrator ロールを持った状態で始めます。

Administrator ロールはシステムが用意したロールなので、修正したり削除したりできません。権限を狭めて同僚に与えたい場合は、Administrator を直す代わりに、下記のように新しいロールを別に作って与えればよいです。

「商品登録担当」ロールを作る

それでは、服屋の Space に同僚へ与える「商品登録担当」ロールを実際に作ってみます。このロールは商品(Content)を Read・Create・Edit できますが、削除したり発行したりはできないようにします。

  1. 左側のメニューで Roles & Permissions を押してください。
  2. 一覧の右上の 作成 ボタンを押してください。
  3. Role詳細 タブの名前欄に 商品登録担当 を入力してください。説明欄は空けておいてもかまいません。

ロール作成画面の Role 詳細タブ。名前に「商品登録担当」を入力した状態

次に、このロールが商品(Content)に対してできる操作を定めます。操作は 許可 リストに一行ずつルールとして入れ、同じ行で適用する範囲(Content Type)も一緒に選びます。

  1. Content タブへ移動してください。
  2. 許可 の下の + を押してルールを一行追加してください。
  3. その行で操作を Read に、適用する Content Type を「商品」に選んでください。(作成者・Tag 欄は「任意の…」のままにしておくと全体に適用されます。)
  4. 同じ方法で CreateEdit のルールも一行ずつ加えてください。三行とも Content Type は「商品」のままにします。
  5. 削除(Delete)と発行(Publish)は許可に入れないでください。許可に入れなかった操作は自動的に拒否されるので、同僚は商品を削除したり外部に公開したりできません。

Content 権限タブで Read・Create・Edit の三つのルールを「商品」に限定して許可した状態

  1. 右上の 保存 ボタンを押してください。

一覧に 商品登録担当 が現れたら、ロールが作られたということです。最初からあった Administrator と一緒に表示されます。

Roles & Permissions の一覧に「商品登録担当」と「Administrator」が一緒に見える画面

作ったロールを同僚に与える

ロールを作ったからといって、自動的に誰かに適用されるわけではありません。作ったロールはメンバーに付与してはじめて効力が生じます。

同僚を Space に割り当てるとき、その Space の中で持つロールを一緒に選びます。このとき、いま作った 商品登録担当 を選べばよいです。すでに Space に入っている同僚なら、メンバー一覧でその同僚のロールを変えて適用することもできます。一人のメンバーに複数のロールを一緒に与えることもできます。このときは各ロールが許可する操作がすべて合わさり、どれか一つのロールでも許可された操作なら、そのメンバーは行えます。(拒否が許可より優先されるのは同じロールの中だけです。あるロールで拒否していても、別のロールが許可すれば、その操作は行えます。)

メンバーを Space に割り当ててロールを選ぶ具体的な手順は、組織とスペース で扱います。

次にすること

  • 組織とスペース: 同僚を Space に割り当て、いま作ったロールを付与します。
  • トークン: 人ではなく外部のサイトやプログラムがコンテンツを読んだり書いたりできるようにするアクセストークンを扱います。ここで作ったロールはトークンにも付きます。Delivery Access Token に付ければロールがそのトークンの読み取り範囲を、Space Access Token に付ければ読み書きの範囲を定めます。発行と管理の権限は二つのトークンで別々になっているので、上の Space 設定 の一覧で片方だけをオンにすることもできます。
  • API リファレンス: プログラムからロールを直接作ったり権限ルールを扱ったりするときに必要な、リクエスト形式のような技術仕様を扱います。