1.2. 用語

OAuth2 の用語ごとに、リソースサーバーは保護されたリソースをホストするサーバーであり、保護されているリソース要求を受け入れて応答できます。

リソースサーバーは通常、保護されているリソースへのアクセスを付与すべきかどうかを決定するために、一定種類の情報に依存します。RESTful ベースのリソースサーバーの場合、その情報は通常セキュリティートークンで実行されます。通常、サーバーへのすべてのリクエストとともにベアラートークンとして送信されます。セッションに依存する Web アプリケーションは、通常、ユーザーのセッションにその情報を保存し、リクエストごとにその情報を取得して取得します。

Red Hat Single Sign-On では、機密 クライアントアプリケーションはリソースサーバーとして機能します。このクライアントのリソースとそれに対応するスコープは、認可ポリシーのセットで保護され、管理されます。

リソースは、アプリケーションと組織のアセットの一部です。これには、1 つ以上のエンドポイント、HTML ページなどの従来の Web リソースなどを指定できます。認可ポリシーの用語では、リソースは保護される オブジェクト です。

すべてのリソースには、単一リソースまたはリソースセットを表す一意の ID があります。たとえば、すべての銀行口座の一連の認可ポリシーを表し、定義する銀行口座リソース を管理できます。ただし、Alice's Banking Accountという名前の別のリソースを使用することもできます。このリソースは、1 人の顧客が所有する単一のリソースで、独自の認可ポリシーのセットを持つことができます。

リソースのスコープは、リソースで実行できるアクセスのバインドエクステントです。認可ポリシーの用語では、スコープはリソースに論理的に適用できる多くの 動詞 の 1 つです。

通常、指定リソースで実行できることを示します。スコープの例には view、edit、delete などがあります。ただし、スコープはリソースによって提供される特定の情報に関連付けることもできます。この場合、プロジェクトリソースとコストスコープを設定できます。コストスコープを使用して、ユーザーがプロジェクトのコストにアクセスする特定のポリシーおよびパーミッションを定義するために使用されます。

この簡単なパーミッションと非常に一般的なパーミッションについて考えてみましょう。

パーミッション は、アクセスが許可されるかどうかを判別するために評価される必要のあるポリシーと保護されるオブジェクトを関連付けます。

Red Hat Single Sign-On は、シンプルなものから非常に複雑なルールベースの動的パーミッションまで、さまざまなパーミッションストラテジーを構築する豊富なプラットフォームを提供します。柔軟であり、以下に役立ちます。

ポリシーは、オブジェクトへのアクセスを付与するために満たさなければならない条件を定義します。パーミッションとは異なり、保護されているオブジェクトは指定しないでくださいが、指定のオブジェクトへのアクセスに対して満たさなければならない条件 (リソース、スコープ、またはその両方など) は指定しないでください。ポリシーは、リソースの保護に使用できるさまざまなアクセス制御メカニズム (ACM) に関係があります。ポリシーを使用すると、属性ベースのアクセス制御 (ABAC)、ロールベースのアクセス制御 (RBAC)、コンテキストベースのアクセス制御またはこれらの組み合わせのストラテジーを実装できます。

Red Hat Single Sign-On は、ポリシーの概念と、集約ポリシーの概念を提供することで、それらの定義方法を活用しています。ここでは、ポリシーのポリシーを構築し、評価の動作も制御することができます。指定のリソースへのアクセスするために満たさなければならないすべての条件で 1 つの大規模なポリシーを作成する代わりに、Red Hat Single Sign-On の Authorization Services のポリシー実装は divide-and-conquer 手法に従います。つまり、個別のポリシーを作成して、異なるパーミッションで再利用し、個々のポリシーを組み合わせてより複雑なポリシーをビルドできます。

ポリシープロバイダーは、特定のポリシータイプの実装です。Red Hat Single Sign-On は、対応するポリシープロバイダーが関係する組み込みポリシーを提供し、特定の要件に対応するために独自のポリシータイプを作成できます。

Red Hat Single Sign-On は、独自のポリシープロバイダー実装でプラグインするために使用できる SPI(サービスプロバイダーインターフェイス) を提供します。

パーミッションチケットは、認可サーバーによってフォームが決定される不透明な構造を提供する、User-Managed Access (UMA) 仕様で定義されている特別なタイプのトークンです。この構造は、クライアント、アクセスコンテキスト、および認可データの要求に適用する必要のあるポリシー (要求側のトークン [RPT]) に対し、リソースやスコープを表します。

UMA では、パーソナツーの共有と人対組織共有にも対応するために、パーミッションチケットが重要です。認可ワークフローのパーミッションチケットを使用すると、リソースの所有者とリソースサーバーがこれらのリソースへのアクセスを管理する粒度の細かいポリシーに基づいて、リソースの所有者とリソースサーバーでリソースを完全に制御できます。

UMA ワークフローでは、リソースサーバーにパーミッションチケットが発行され、保護されているリソースにアクセスするクライアントに対するパーミッションチケットを返します。クライアントがチケットを受け取ると、チケットを認可サーバーに送信して、RPT(認可データを保持する最終トークン) のリクエストを行うことができます。

パーミッションチケットの詳細は、ユーザー管理アクセス および UMA 仕様を参照してください。