アプリケーションの承認レイヤーで確認されます。役割を使用する方法と、ポリシーを使用する方法です。プラットフォームから引き継がれたものです。アプリケーションから使用されています。技術的には、役割とはプレーンな文字列です。オブジェクトで存在がチェックされます)。アプリケーションでは、特定の認証済みユーザーに一連のアクセス許可をマップするために使用します。オブジェクトによって識別されます。コレクションを公開します。リストが用意されます。要求とは基本的には、ユーザーの状態に関するステートメントです。つの一般的な要求です。ストアによって変わります。ソーシャル認証を使用する場合、役割は存在しません。検出するのが目的です。エンドポイントを呼び出すための要件を定義します。通常、ユーザーの役割はデータベースに格納され、ユーザーの資格情報を検証するときに取得します。アカウントに結び付けられます。メソッドがあり、これを実装する必要があります。クラスでは、認証プロセスによって用意される要求のコレクションで、役割要求を利用できるかどうかをチェックすることにより、このようなしくみを実現します。メソッドの呼び出しを試みる際には、そのユーザーの役割をチェックできる必要があります。チェックできなければ、ユーザーは、セキュリティ保護されたメソッドの呼び出しを拒否されます。属性は、コントローラーまたはその一部のメソッドを保護する宣言型の方法です。...}引数を使用せずに指定した場合、この属性はユーザーの認証状態のみをチェックします。追加属性がサポートされます。プロパティは、一覧に記述された役割のユーザーに、アクセス権が付与されることを示します。属性を適用したり、独自のフィルターを記述します。以上の認証方式を受け取ることもできます。コンポーネントの一覧を取得します。方式経由で認証済みで、なおかつ一覧に記述されたいずれかの役割を持つ場合のみ許可されることが示されています。プロパティに渡す文字列値は、アプリケーションの起動時に登録された認証ミドルウェアと一致する必要があります。認証ミドルウェアが、ハンドラーを複数持つサービスに置き換わることに注意してください。その結果、認証方式はハンドラーを選択するラベルになります。参照することをお勧めします。属性により提供される情報は、システム提供の承認フィルターで使用されます。承認フィルターは、要求された操作をユーザーが実行できるかどうかをチェックします。フィルターよりも先に実行されます。ユーザーが承認されない場合、承認フィルターはパイプラインを実行せずに要求をキャンセルします。カスタム承認フィルターを作成できますが、たいていの場合、この作業は必要はありません。実際には、既定のフィルターによって利用されている既存の承認レイヤーを構成することをお勧めします。役割は、ユーザーが実行できること、できないこと基づいて、アプリケーションのユーザーをグループ分けする簡単な方法です。役割にはあまり高い表現力はありません。少なくとも、大半の最新アプリケーションのニーズを満たせるほどの表現力は備わっていません。例として、比較的シンプルな承認アーキテクチャを考えてみましょう。ユーザーに対応するものとします。つの役割を中心に構築でき、各グループがアクセスできるコントローラーとメソッドを定義します。特定の役割内でユーザーができること、できないことを示す却下に関する微妙な差異について、問題が発生しました。システムにアクセスできるユーザーがいます。その中には、顧客データの編集のみ承認されているユーザーもいれば、コンテンツを操作することのみ承認されているユーザーもいます。役割は基本的にはフラットな概念です。示すようなシンプルな階層はどうすればフラットになるでしょうか。つの異なる役割を作成することはできるでしょう。却下の数が増加するとすぐに、必要な役割も大幅に増えることになります。つになっている単純なシナリオや事例は例外として、このような単純な演習でさえ、承認を処理するうえで、役割が最も効果的な方法ではない可能性が示されています。あらゆることに、異なる要件があります。そこで考えられたのが、ポリシーベースの承認です。ロジックを分離するために、ポリシーベースの承認フレームワークが設計されています。簡単に言うと、ポリシーは、要件のコレクションとして考案されたエンティティです。要件自体は、現在のユーザーが満たす必要のある条件です。ユーザーが認証済みであるというのが最も単純なポリシーです。ユーザーが特定の役割に関連付けられているポリシーもよく使われます。ユーザーに特定の要求がある、または特定の値を含む特定の要求があるというポリシーも使われます。関するアサーションです。オブジェクトを作成します。インスタンスを構築します。トークンが読み取られます。定義済みの拡張メソッドの中に役立つ要件を定義するものがない場合は、いつでも独自のアサーションを使用して新しい要件を定義できます。オブジェクトを受け取ってブール値を返すラムダを受け取ります。単なる条件ステートメントです。複数回連結する場合は、すべての役割がユーザーから渡される必要があることに注意してください。条件で表現することを考えている場合も、アサーションを利用できます。ユーザーが許可されます。ポリシーの登録ポリシーを定義するだけでは不十分です。承認ミドルウェアを使用してポリシーを登録することも必要です。メソッドで承認ミドルウェアをサービスとして追加します。});}このミドルウェアに追加される各ポリシーには名前があります。属性内でポリシーを参照するために使用されます。属性では、宣言によりポリシーを設定できます。オブジェクトを返すことができます。ページにリダイレクトするか、構成に応じてそのいずれかを承認ミドルウェアに指示します。リダイレクトは行われません。