SSOアクセス制御
アクセス制御とは？ 
FastCommentsのSSOアクセスコントロール(RBACとも呼ばれます)を使用すると、ユーザーは特定のページやコメントスレッドにのみアクセスできるよう制限できます。さらに、ユーザーは同じグループ内のユーザーにのみ @mention できます。
詳細
Users と、オプションで Pages をグループに配置できます。
Users をグループに配置し、ウィジェット設定で Limit Comments by SSO User Groups を有効にすると、ユーザーは同じグループに属するユーザーのコメントのみを表示でき、同じグループ内のユーザーにのみ @mention できるようになります。
さらに、Pages をグループに配置することもでき、その場合ユーザーはアクセス権のあるページのコメントのみにアクセスできます。
これを「ユーザーレベル」グループと「ページレベル」グループと呼びます。
では、どちらが適切でしょうか?
ユーザーレベルグループを使用すべき場合...
- 同じ
urlId値(ページURLや記事ID)を使用しつつ、グループごとにコメントを制限したい場合。 - 例えば、「新規ユーザー」と「ベテランユーザー」のグループを作り、同じページ上でお互いのコメントを見えなくしたい場合。
ページレベルグループを使用すべき場合...
- グループごとに特定のページがある場合。
- 例えば、「公開ページ」グループのユーザーが「トップシークレット」の記事を閲覧できないようにしたい場合。
仕組み
FastComments のアクセス制御は、Pages と Users を目的のグループに割り当てることで機能します。
グループは単純に文字列識別子で、GREEN や abc-123 のようなものです。
Users と Pages は 1 つのグループに限定されません。制限はそれぞれ 100 と 1000 のグループです。
許可されていないページへのアクセス
ユーザーがアクセス権のないページにアクセスしようとすると、以下のようなエラーメッセージが表示されます:
メッセージテキストはカスタマイズできます。
仕様
複数のユーザーがどのようにやり取りするかを定義し、それをテストすることは複雑です。以下は、当社がアクセス制御のために従っている仕様です。実装をテストする際にご利用いただけます:
グループ ID が null のページ、グループ ID が null のユーザー - アクセス可能であるべき。
グループ ID が null のページ、グループ ID を持つユーザー - アクセス可能であるべき。
グループ ID を持つページ、グループ ID が null のユーザー - アクセス可能であるべき。
グループ ID を持つページ、空のリストを持つユーザー - アクセス不可であるべき。
グループ ID を持つページ、グループ ID を持つユーザー - 共通部分が存在する場合 - アクセス可能であるべき。
グループ ID を持つページ、グループ ID を持つユーザー - 共通部分が存在しない場合 - アクセス不可であるべき。
グループ ID の空のリストを持つページ(誰もアクセスできない)、ユーザーが null - アクセス不可であるべき。
SSO ユーザー A = グループ ID 未定義(null = フルアクセス)。
SSO ユーザー B = グループ ID 未定義(null = フルアクセス)。
A は B を @ できる。
SSO ユーザー A = グループ ID 未定義(null = フルアクセス)。
SSO ユーザー B = グループ ID 定義済み。
A は B を @ できる。
SSO ユーザー A = グループ ID 定義済み。
SSO ユーザー B = グループ ID 未定義(null = フルアクセス)。
A は B を @ できる。
SSO ユーザー A = グループ ID = [a]。
SSO ユーザー B = グループ ID = [b]。
A は B を @ できない。
SSO ユーザー A = グループ ID = [a]。
SSO ユーザー B = グループ ID = [a, b]。
A は B を @ できる。実装
別グループのユーザーへのメンション
もし2人のユーザーがそれぞれ異なるグループの集合に属しており、交差がない場合、互いに@mentionすることはできません。
ユーザーが手動で@mentionを入力してコメントを送信した場合、それはプレーンテキストのまま残ります。相手のユーザーはタグ付けされません。
グループの管理
GroupsはそれぞれPagesおよびSSOUsers API リソースを使用して定義されます。
Pages API はページにアクセスできるグループの集合を定義するために呼び出すことができます。デフォルトでは、すべてのグループとグループに属していないユーザーにもアクセス権があります。
同様に、SSOUsers API は各ユーザーに関連付けられたグループを定義するために呼び出すことができます。
両方のリソースについて、グループを設定または更新するタイミングに制限はありません。
ユーザー同士の@mentionのみを制限したい場合、Pages を考慮する必要はありません。
注意!
SSOユーザーグループの定義と更新は API を使用する必要はなく、代わりにコメントウィジェットに渡される SSO ペイロード内でグループ ID を定義することで自動的に更新できます。ただし、グループのリストが大きい場合は、ユーザーが各ページ読み込みごとにこのペイロードを送信する必要があるため推奨されません。
API呼び出しの例
ここでは FastComments API を呼び出してアクセス制御を設定する方法を説明します。
始める前に、Group 構造を明示的に作成する必要はないことに注意してください。Groups は単に Users と Pages に追加される識別子です。ユーザーやページにグループを追加すると、そのグループは自動的に「作成」されます。
まず、User A と User B の2人のユーザーを作成します。最初は両方とも Group X に入れます：
次に Page を作成します。これを Confidential Page と呼びます。現時点ではこれらのユーザーは誰もこのページにアクセスできません。なぜならこのページは CONFIDENTIAL グループに属しているからです：
User A と User B は現時点で新しいページに アクセスできません。しかし、両者は同じグループ GROUP-X にいるため、お互いを @mention することはできます。
User B を更新して、ページにアクセスできるようにしましょう：
User B は現在両方のグループに属しています。ユーザー同士は引き続き @mention できますが、閲覧できるのは User B だけです。
User B が機密ページのみ閲覧できるようにしましょう：
これで User B は機密ページを閲覧できますが、両ユーザーは異なるグループにいるため互いに @mention することはできません。
しかし、アクセス制御の一部でないユーザーはページにアクセスできてしまいます。これを防ぐには、SSO ユーザーの groupIds が null に設定されていないことを確認してください。例えば、すべてにアクセスできる User C を作成してみます：
groupIds を null に設定すると、そのユーザーはアクセス制御の制限を受けないことを示します。
次に、全員がアクセスできるページを作成します：
accessibleByGroupIds を null に設定すると、この Page はアクセス制御の対象外となり、両方のユーザーがアクセスできるようになります。
これでアクセス制御のための API 実演は完了です。