OAuth 2 ポリシーの実装

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

oauth implementation federated
  1. ユーザまたはアプリケーションがクライアントアプリケーションに定義されている有効な許可種別を使用してアクセストークンを要求します。

  2. ユーザまたはアプリケーションがアクセストークンを含む要求を送信します。統合ポリシーが、適切な形式のクエリパラメータまたは認証ヘッダーとして指定されたアクセストークンを検証します。

  3. 統合ポリシーが OAuth プロバイダに対してトークンを検証します。パフォーマンス向上のために、Mule では認証サーバへのコールがキャッシュされ、トークンの存続期間中に 1 回だけ実行されます。

    OpenId、PingFederate、または外部プロバイダを使用する OAuth 2.0 アクセストークン適用ポリシーが有効で、API が Mule 4 でデプロイされている場合、OAuth プロバイダから返されるクライアント ID は、クライアント ID 適用ポリシーによって検証されます。

  4. Mule 4 では、Mule 3 とは異なり、フローで実行されるすべての要求は、OAuth プロバイダで提供される情報で強化されますが、この情報は、​[Expose Headers (ヘッダーを公開)]​ チェックボックスを有効にしてポリシーに明示的に設定しない限り、ユーザには返されません。

    oauth policy implementation concept 7ad82

    次の例では、トークン検証応答として返される 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"}

    このトークン検証応答は変化することがあります。​[Expose Headers (ヘッダーを公開)]​ が有効な場合、プロキシは、​scope​、​expires_in nodes​、および ​x-rate-limit​ ヘッダー (​x-ratelimit-remaining​、​x-ratelimit-limit​、および ​x-ratelimit-reset​) を除く、受信したすべてのヘッダーをバックエンド実装に送信します。

可能な応答:

応答 理由

200

トークンは正常に検証されました。

400

不正な要求エラー。原因として、トークンが送信されなかった、トークンがクエリパラメータとヘッダーの両方で送信された、または、トークンがヘッダーとして送信されたがプレフィックス「Bearer」がなかった、が考えられます。

401

トークンは未承認です。

403

この応答コードの原因として、OAuth プロバイダに対する検証、スコープの検証、またはクライアント ID 適用ポリシーでのエラーが考えられます。

Mule 4 実装シナリオ

ここでは、図で最も一般的な実装シナリオを示します。

正常に検証されたトークン

次の図は、OpenId、PingFederate、および外部プロバイダを使用する OAuth 2.0 アクセストークン適用ポリシーで正常に検証されたトークンを表します。

oauth implementation diagram2

次の図は、OpenAM ポリシーに対して正常に検証されたトークンを表します。

successful validated openam

未承認トークン

次の図は、​Unauthorized (401)​ (未承認 (401)) トークンエラーを表します。

unauthorized token

アクセス拒否

次の図は、OAuth プロバイダエラーからの ​Forbidden (403)​ (アクセス拒否 (403)) エラーを表します。

forbidden error

無効なスコープ

次の図は、無効なスコープエラーを表します。

invalid scopes

失敗したクライアント ID 適用検証

次の図は、​Client ID Enforcement Validation Failed​ (クライアント ID 適用検証が失敗) エラーを表します。

oauth implementation diagram3

このエラーは OpenAM ポリシーでは無効です。

不正な要求

次の図は、​Bad Request (400)​ (クライアント ID 適用検証が失敗) エラーを表します。

bad request

Mule 4 HTTP ヘッダー

統合ポリシーは、アクセストークンの検証時に統合サーバから返されたユーザプロパティが含まれる特別なヘッダーを HTTP 要求に追加します。これらのヘッダーは ​x-agw-*​ プレフィックスで識別されます。また、送信 HTTP 要求にのみ設定されるため、統合ポリシーの後に適用される他のポリシーは、これらの特別なヘッダーを受信することができません。
たとえば、​x-agw-uid​ ヘッダーを設定する OpenId Connect アクセストークン適用ポリシーがある場合、他のポリシーがこのヘッダーを抽出することはできません。
DataWeave を使用すると、統合サーバで返されるユーザ情報を取得できます。

たとえば、​x-agw-username​ で渡されたユーザ名を取得するには、以下を使用します。

#[authentication.properties.userProperties.username]

x-agw-uid​ で渡された UID を取得するには、以下を使用します。

#[authentication.properties.userProperties.uid]

ユーザプロパティは、統合実装に応じて異なります。標準的な経験則として、特定の ​X-AGW-{key}=value​ ヘッダーの値は、式 ​#[authentication.properties.userProperties.{key}]​ を使用して取得できます。
さらに、式 ​[#authentication.properties.userProperties.*]​ はイントロスペクションエンドポイントで検出されたすべての要求を返します。

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub