---
schema_version: "1"
id: 18d4ea6ff1f6c965f07c6a3a3e894d8ac3dec2f976a7d396694f7c6a3af6729a
title: OpenAM OAuth 2.0 トークン適用ポリシー
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-gateway/policies-mule3-openam-oauth-token-enforcement-policy.md
canonical_url: https://docs.mulesoft.com/jp/mule-gateway/policies-mule3-openam-oauth-token-enforcement-policy
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 59a38db9970b0a3023270bb2a0224a5203b843b7ae27bc0494619d2bc965abfe
description: MuleSoft Documentation Site
latest: true
---
# 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-クライアントと許可種別)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']]`

<table class="tableblock frame-all grid-all" style="width: 80%;">
<colgroup>
<col style="width: 10%;">
<col style="width: 90%;">
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">_agwUser マップキー</th>
<th class="tableblock halign-left valign-top">説明</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p><strong>uid</strong></p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>アプリケーションを使用して API をコールしているエンドユーザーのユーザー ID。</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p><strong>グループ</strong></p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>ユーザーが関連付けられているグループの配列。</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p><strong>email (メール)</strong></p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>ユーザーのメール。</p>
</div></div></td>
</tr>
</tbody>
</table>

## [](#ユーザーログイン情報の取得)ユーザーログイン情報の取得

ポリシーは、アウトバウンドプロパティが含まれる 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 メッセージヘッダーを形成する、返された情報を示しています。

```text
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 バージョンへのアクセスを保護するしくみを示しています。

![API 認証プロセスのフローチャート図](/mulesoft/current/ja-jp/mule-gateway/_images/openam-oauth-token-enforcement-policy-0fbb9.png)

- まず、クライアントアプリケーションは 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`​ を返します。

## [](#関連情報)関連情報

- [api-manager::apply-oauth-token-policy-task.adoc](#api-manager::apply-oauth-token-policy-task.adoc)
- [ポリシーの適用](https://docs.mulesoft.com/jp/mule-gateway/policies-included-apply)
- [SAML 2.0](https://docs.mulesoft.com/jp/access-management/external-identity#instructions-for-saml-configuration)