1. Homepage
  2. Mule ゲートウェイ
  3. Mule 3 のポリシー
  4. 内部ポリシー

  5. OpenAM OAuth 2.0 トークン適用ポリシー

OpenAM OAuth 2.0 トークン適用ポリシー

Anypoint Platform で API に適用する適用ポリシーは、OpenAM 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイント、または PingFederate 認証サーバーに接続します。ポリシーは、次の設定に従ってアクセス権を適用します。

  • アクセス権の範囲 (省略可能)

  • OAuth クライアント

  • 認証サーバーへのプロキシ接続

ポリシーを API に適用するには、ポリシーの一般的な適用手順を使用します。アクセス権の範囲は、ポリシーを適用するときに設定します。設定タスクに加えて、アクセストークンを要求するユーザーのログイン情報の検証を実装できます。

前提条件

  • Anypoint Platform 組織が、OpenAM、OpenID Connect、PingFederate のいずれかを使用して統合組織としてセットアップされていること。

  • ユーザーが Anypoint Platform 組織のシステム管理者であるか、API を作成または管理する権限を持っていること。

PingFederate と OpenAM の OAuth クライアントと許可種別

OpenAM は 2 種類の OAuth クライアントをサポートしています。

  • 機密クライアントは、ログイン情報を機密に保ちます。次の許可種別が含まれます。

    • クライアントログイン情報

    • 暗黙的

    • Password (パスワード)

  • 公開クライアントは、ログイン情報を他の関係者と共有します。次の許可種別が含まれます。

    • 認証コード

    • 暗黙的

    • Password (パスワード)

各クライアント種別は、4 つの OAuth 許可種別のうちの 3 つをサポートしています。このため、OpenAM クライアントの設定時には、4 つの許可種別のうち 3 つのみ選択できます。残りの許可種別は、もう一方のクライアントに属しているため使用できません。選択した許可種別に応じて、OpenAM クライアントのプロパティを公開または機密のどちらにするかを決定します。

PingFederate クライアントでは、OAuth 許可種別の任意の組み合わせを使用できます。許可種別には、暗黙的、クライアントログイン情報、リソースオーナーのパスワードログイン情報、認証コードがあります。PingFederate ユーザーは、自由な順序で許可種別を有効または無効にできます。

ユーザー検証

API には、アクセストークンを要求するユーザーのログイン情報のチェックを含めることができます。MEL 式を使用して、有効なトークンに関連付けられているユーザー情報のマップにアクセスします。フロー変数 ​['_agwUser']​ を使用します。マップ内の特定の値にアクセスするには、値を直接指定します。

次の例は、アプリケーションを使用して API をコールしているエンドユーザーのユーザー ID にアクセスします。

#[flowVars['_agwUser']['uid']]

_agwUser マップキー 説明

uid

アプリケーションを使用して API をコールしているエンドユーザーのユーザー ID。

グループ

ユーザーが関連付けられているグループの配列。

email (メール)

ユーザーのメール。

ユーザーログイン情報の取得

ポリシーは、アウトバウンドプロパティが含まれる Mule メッセージを返します。アウトバウンドプロパティには、外部で認証されたどのユーザーまたはアプリケーションが API を使用しているかに関する情報が含まれます。受信要求トークンの許可種別に応じて、これは異なるヘッダー内で表されます。

  • 要求のトークンの許可種別が、リソースオーナーのログイン情報、暗黙的、認証コードの場合は、要求を実行したユーザーの ID がヘッダー X-AGW-userid に含まれます。

  • 要求のトークンの許可種別が、クライアントのログイン情報の場合は、要求を実行したユーザーの ID がヘッダー ​X-AGW-client_id​ に含まれます。

2 つのプロパティのいずれかが参照可能で、フロー内の後続の任意のコンポーネントによってプロキシ内部で使用されます。

プロキシの出力を生成する HTTP Connector は、受信したすべてのアウトバウンドプロパティを HTTP メッセージヘッダーに変換します。プロキシを通過した後に API に到達したメッセージには、次のいずれかの HTTP ヘッダーが含まれています。

  • ユーザー名を含む X-AGW-userid

  • クライアント ID を含む X-AGW-client_id

トークン検証応答の例

次の例は、HTTP メッセージヘッダーを形成する、返された情報を示しています。

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Date: Mon, 09 Mar 2015 19:08:07 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.1.1
Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
{"uid":"john.doe","mail":"john.doe@example.com","scope":["uid","mail","cn","givenName"],"grant_type":"password","cn":"John Doe Full","realm":"/","token_type":"Bearer","expires_in":580,"givenName":"John","access_token":"fa017a0e-1bd5-214c-b19d-03efe9f9847e"}

ポリシーの実装

次の図は、ポリシーが既存の OpenAM または PingFederate 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイントと連携して API バージョンへのアクセスを保護するしくみを示しています。

1 アプリケーションが API にアクセスすることを承認 2 ユーザーログイン情報を送信 3 有効なトークンを送信 4 API をコール 5 範囲とヘッダー/パラメーター内のトークンを確認 6 ヘッダー/パラメーター内のトークンと範囲を検証 7 API がコールされる

  • まず、クライアントアプリケーションは API コールを実行する前に認証サーバーから直接トークンを要求します。クライアントアプリケーションは、ユーザーログイン情報を使用して認証することによって、この要求を行います。

  • サーバーはクライアントアプリケーションに有効なトークンを提供します。

  • 次に、クライアントアプリケーションは、有効なトークンを API コール内で送信します。

  • Mule は、OpenAM、OpenID Connect、または PingFederate OAuth トークン適用ポリシーによって制御され、ヘッダーまたはクエリパラメーター内のトークンが有効で、正しい範囲に一致していることを確認します。

  • ポリシーは OpenAM 認証サーバー、OpenID Connect トークンイントロスペクションエンドポイント、または PingFederate 認証サーバーを呼び出して、トークンを検証し、範囲を確認します。

  • 最後に、API はクライアントアプリケーションからコールを受信します。

パフォーマンス向上のために、Mule では認証サーバーへのコールがキャッシュされ、トークンの存続期間中に 1 回だけ実行されます。OAuth トークンが有効でない場合、認証サーバーはエラーを返します。次に例を示します。

  • OpenAM 11.0.0 は ​404 NOT FOUND​ を返します。

  • OpenAM 12.0.0 は ​400 BAD REQUEST​ を返します。

  • PingFederate は ​403 FORBIDDEN​ を返します。

関連情報