アクセス制御による認可

認可とは、ウェブアプリケーションのさまざまな部分やアセットへのアクセスをユーザーに付与するプロセスです。ユーザーを認可する一般的な方法はアクセス制御によるものであり、サイト管理者がどのリソースにアクセスするためにユーザーやその他のエンティティにどのような権限を付与する必要があるかを定義します。

認可は認証と混同してはなりません。認証とは、ユーザーが自分であると主張する人物であることを検証するプロセスであり、通常はアカウントの認証情報を提供することで行われます。ユーザーが認証された後も、ユーザーが要求したリソースにアクセスできることを確認するために、すべてのリクエストで認可プロセスを実行する必要があります。

GraphQL経由でアプリケーションにアクセスする際、ユーザーがスキーマから要求した要素へのアクセス権を持っているかどうかを検証する必要があります。認可ロジックはGraphQL層内にコーディングすべきでしょうか？

答えはノーです。graphql.orgのドキュメントが明確にしているように、認可ロジックはビジネスロジック層に属し、そこからGraphQLがアクセスします。このようにして、アプリケーションは認可のための単一の信頼できる情報源（つまりWordPressが提供するもの）を持つことができます：

Gato GraphQLはこの原則を尊重し、WordPressが提供する認可メカニズムを反映（およびエンジンの下で委任）しています。

​

アクセス制御ポリシー

アプリケーションに実装できる複数のアクセス制御ポリシーの中で、最も普及している二つはRole-Based Access Control（RBAC）とAttribute-Based Access Control（ABAC）です。

WordPressとGato GraphQLは、両方をサポートしています。

Role-Based Access Controlでは、ロールに基づいて権限を付与し、そのロールをユーザーに割り当てます。例えばWordPressには、すべてのリソースにアクセスできるadministratorロールと、ブログ投稿の作成・公開、作成のみ、または閲覧のみなど、さまざまな度合いで制限された権限を持つeditor、author、contributor、subscriberのロールがあります。

Attribute-Based Access Controlでは、ユーザー、アセット、環境条件（時間帯や訪問者のIPなど）を含むさまざまなエンティティに割り当て可能なメタデータに基づいて権限が付与されます。例えばWordPressでは、edit_others_postsケイパビリティを使用して、ユーザーが他のユーザーの投稿を編集できるかどうかを検証します。

一般的に言えば、ABACはRBACより望ましいとされています。なぜなら、きめ細かい制御で権限を設定でき、権限の目的が明確であるためです。

例えばWordPressでは、editorロールはedit_others_postsケイパビリティを持っていますが、authorロールを持つ人が別の著者の投稿を編集できるようにしたい場合があります。しかし、その際にエディターに付与される権限のセット全体（他の著者の投稿を削除する権限なども含む）を付与せずに済ませたいでしょう。したがって、edit_others_postsケイパビリティを付与してこの条件をチェックする方が、editorロールをチェックするよりも適切です。

​

可視性の定義

ユーザーがGraphQLスキーマの要求されたフィールドにアクセスする権限を持っていない場合、返されるエラーはどうあるべきでしょうか？

スキーマに望む可視性、つまりパブリックまたはプライベートに応じて、二つの可能性があります。

パブリックスキーマの場合、公開されるGraphQLスキーマはすべてのユーザーで同一であり、各フィールドにはアクセスに必要な権限が記述されています。アクセスできないフィールドをリクエストした場合、エラーメッセージはなぜユーザーにアクセスが許可されないかを説明します。

プライベートスキーマの場合、GraphQLスキーマはユーザーごとにカスタマイズされ、そのユーザーがアクセスできるフィールドのみが公開されます。アクセスできないフィールドをリクエストした場合、エラーメッセージはそのフィールドが存在しないと示します。

​

ユーザーインターフェースによるアクセス制御

Gato GraphQLでは、アクセス制御ルールはランタイムにスキーマへ注入されます。これはアクセス制御リストを通じたユーザー定義の設定として行われます。これにより、GraphQL層はコードの更新やスキーマの再コンパイルを必要とせず、アクセス制御ポリシーの変更を即座に反映します：

サイト管理者はACLを設定し、以下を選択します：

• 検証するフィールド
• 以下から選択する検証ルール：
  • ユーザーはログインしている必要があるか？
  • ユーザーはログアウトしている必要があるか？
  • ユーザーは特定のロールを持つ必要があるか？
  • ユーザーは特定のケイパビリティを持つ必要があるか？
• ルール固有の設定：
  • どのロールか？
  • どのケイパビリティか？
• 可視性：
  • デフォルト（スキーマに割り当てられているものと同じ）？
  • パブリック？
  • プライベート？