Disclaimer 当資料の位置づけ当資料は IBM DataPower Gateway (IDG) における OAuth 機能の概要と実装方法および考慮点をまとめたものです Firmware v を前提としています注意事項当資料に含まれる情報は可能な限り正確を期しております

(1)

IBM DataPower Gateway (IDG)

OAuth構成ガイド

(2)

2

Disclaimer



当資料の位置づけ



当資料は、IBM DataPower Gateway (IDG) におけるOAuth機能の概要と、実装方

法および考慮点をまとめたものです。



Firmware v7.2.0.2を前提としています。



注意事項



当資料に含まれる情報は可能な限り正確を期しておりますが、当資料に記載された内

容に関して何ら保証するものではありません。ここでの記載内容はあくまでも支援情

報であり、使用者の責任において取扱われるものとし、資料の内容によって受けたい

かなる損害に関して一切の保証をいたしません。



製品の新しいリリース、修正などによって動作／仕様が変わる可能性がありますので、

必ずマニュアル等で最新の情報をご確認ください。

(3)



OAuth概要



OAuth構成要素



IDGにおけるOAuthプロトコルのサポート



OAuth構成トポロジー



IDGが認証・許可するパターン



OAuth処理フロー (Basic認証 / Form認証)



認証と許可が分離するパターン



IDGの冗長構成について



OAuth構成方法



OAuth構成手順概要および詳細



OAuthプロセスのカスタマイズ



カスタム・スコープ検査



許可フォームのカスタマイズ



リソース所有者カスタム処理



追加OAuth処理



トークン失効管理



IDGにおけるトークン失効方法



IDGにおけるトークン失効管理



IDG内部キャッシュの利用と考慮点

(4)

4

(5)

OAuth構成要素 (1/2)



リソース・オーナー（Resource Owner）



保護されたリソースへのアクセスを許可するエンティティー



人間の場合はエンド・ユーザーに相当



OAuthクライアント（Client）



リソース・オーナーの許可を得て、リソース・オーナーの代理として保護されたリソー

スに対するリクエストを行うアプリケーション



アクセス・トークンを使用して保護されたリソースにアクセスする



許可サーバー（Authorization Server）



リソース・オーナーの認証とリソース・オーナーからの許可取得が成功した後、アクセ

ス・トークンをクライアントに発行するサーバー



リソース・サーバーと同一サーバーの場合と異なるサーバーの場合がある



リソース・サーバー（Resource Server）



保護されたリソースをホストし、保護されたリソースへのリクエストを受理してレスポ

ンスを返すサーバー

OAuthの詳細についてはRFC 6749を参照

(6)

OAuth構成要素 (2/2)



アクセス・トークン



リソース・オーナーの保護リソースにアクセスするためのクレデンシャル



OAuthクライアントが保護リソースへアクセスする際にリソース・サーバーに送信する



リフレッシュ・トークン



アクセス・トークンを取得するためのクレデンシャル



アクセス・トークンの期限が切れた場合に、許可サーバーから新規アクセス・トークン

を要求したり、同一スコープまたはより狭いスコープを持つアクセス・トークンを要求

するために使用



リソース・サーバーには送信されない

OAuthの詳細についてはRFC 6749を参照

(7)

IDGにおけるOAuthプロトコルのサポート (1/5)



IDGはOAuth 2.0をサポート



厳密には、RFC6749 「The OAuth 2.0 Authorization Framework」のド

ラフト版 (draft-ietf-oauth-v2-31)がベース



プロトコルフロー

(8)

IDGにおけるOAuthプロトコルのサポート (2/5)



2者間フロー



以下のいずれかの場合に使用可能



OAuthクライアント=リソース・オーナー



OAuthクライアントが信頼できる (リソース・オーナーの資格情報を知っている)



以下のグラント・タイプが使用可能



リソース・オーナー・パスワード・クレデンシャル



クライアント・クレデンシャル

許可サーバー

リソース・サーバー

アクセス許可要求認証 / 許可 w/リソース・オーナー資格情報アクセス・トークン (+リフレッシュ・トークン) リソース・アクセス w/アクセス・トークン

リソース・オーナー＆

OAuthクライアント

アクセス・トークン再発行要求 w/リフレッシュ・トークンアクセス・トークン

(9)

IDGにおけるOAuthプロトコルのサポート (3/5)



3者間フロー



リソース・オーナーの資格情報をOAuthクライアントに知らせることなく、OAuthク

ライアントがリソース・サーバーによって保護されたリソースへアクセスすることを

許可することが可能



許可コード (または暗黙的付与)のグラント・タイプを使用

許可サーバー

リソース・オーナー

OAuthクライアント

リソース・サーバー

Initiate アクセス許可要求 (302 リダイレクト) 認証 / 許可 w/リソース・オーナー資格情報アクセス・トークン発行要求 w/許可コード + OAuthクライアント資格情報許可コード (302 リダイレクト) アクセス・トークン (+リフレッシュ・トークン) リソース・アクセス w/アクセス・トークンアクセス・トークン再発行要求 w/リフレッシュ・トークン

(10)

IDGにおけるOAuthプロトコルのサポート (4/5)



以下のOAuthクライアントのロールのいずれかまたは両方をサポート



許可サーバー・エンドポイント (許可エンドポイントおよびトークン・エンドポイント)



IDGは保護されたリソースへのアクセス許可をリソース・オーナーから取得し、OAuthクライア

ントに対してアクセス・トークンを発行する



リソース・サーバーの適用ポイント



IDGはサービス提供者が保持するリソースを保護し、OAuthクライアントが保護されたリソース

へアクセスするための要求に対して応答する



アクセス・トークンを使用して要求の受け入れ可否を判断する



ロールは「OAuthクライアント・プロファイ

ル」にて指定



同じOAuthクライアント・グループに属する

すべてのOAuthクライアント・プロファイル

は、同じロールまたはグループ内で定義され

たロールのサブセットを持っている必要があ

る

(11)

IDGにおけるOAuthプロトコルのサポート (5/5)



OAuthロールが許可サーバー・エンドポイントの場合、グラント・タイプの指定が必要



以下のグラント・タイプをサポート



許可コード



OAuthクライアントは許可コードによってアクセス許可を取得する



3者間フローでのみ使用可能



暗黙的付与 (Implicit)



OAuthクライアントはアクセス・トークンを取得する際に用いられる仲介のクレデンシャルを利用せず (=

暗黙)、直接アクセス・トークンを取得する



3者間フローでのみ使用可能



リソース・オーナー・パスワード・クレデンシャル



OAuthクライアントはリソース・オーナーのパスワード・クレデンシャルを使用してアクセス許可を取得す

る



2者間フローでのみ使用可能



クライアント・クレデンシャル



クライアントのクレデンシャルを使用してアクセス許可を取得する



2者間フローでのみ使用可能



JSON Web Token (JWT)



JWTを使用してアクセス許可を取得する



2者間フローでのみ使用可能



OpenID Connect (OIDC)

(12)

12

(13)

IDGが認証・許可するパターン



IDGにて認証およびOAuth許可を行うことが可能

OAuthクライアント

・アプリケーション

ユーザー情報

IBM DataPower

Gateway (IDG)

許可サーバー・

エンドポイント

認証サーバー

トークン失効情報

トークン失効管理

サーバー

リソース

アプリケーション・

サーバー

リソース・サーバー

リソース・オーナー

モバイル・アプリ

ブラウザー

リソース・サーバー

適用ポイント

(14)

14

OAuth処理フロー (Basic認証 & 許可コード)

IBM DataPower Gateway (IDG)

許可サーバー・エンドポイント＆

リソース・サーバー適用ポイント

リソース・オーナー

OAuthクライアント

リソース・サーバー

302 Found Location: /oauth/authz?response_type=code&client_id=<client> &redirect_uri=<uri>&scope=<scope>&state=<state> POST /oauth_request 401 Unauthorized

WWW-Authenticate: “Basic realm=login”

Basic Authentication Authorization: Basic: <username>:<password>

GET

/oauth/authz?response_type=code&client_id=<client>& redirect_uri=<uri>&scope=<scope>&state=<state>

Scope Accept POST /oauth/authz

selectedscope=<scope>&dp-state=<ticket>& resource-owner=<owner>&redirect_uri=<uri>&scope=<scope> &client_id=<client_id>&approve=true& Authorization Form Publish code 302 Processed Location: <uri>?code=<code>&state=<state> POST /oauth/token

Authorization: Basic: <client_id>:<secret> grant_type=authorization_code&code=<code >&redirect_uri=<uri>

Validate code & Publish token

200 OK 200 OK { "token_type":"bearer", "access_token":“<access_token>", "expires_in":3600, "scope":“<scope>", "refresh_token":“<refresh_token>" } GET /resource

(15)

OAuth処理フロー (Form認証 & 許可コード)

IBM DataPower Gateway (IDG)

許可サーバー・エンドポイント＆

リソース・サーバー適用ポイント

リソース・オーナー

OAuthクライアント

リソース・サーバー

302 Found Location: /form/oauth/authz?response_type=code&client_id=<clien t>&redirect_uri=<uri>&scope=<scope>&state=<state> POST /oauth_request Form Authentication POST /form/j_security_check J_username=<username>&j_password=<password>&login=Log in&originalUrl=/form/oauth/authz?response_type=code&client_id =<client>&redirect_uri=<uri>&scope=<scope>&state=<state>

Scope Accept POST /form/oauth/authz

selectedscope=<scope>&dp-state=<ticket>& resource-owner=<owner>&redirect_uri=<uri>&scope=<scope> &client_id=<client_id>&approve=true& Authorization Form Publish code 200 OK

Set Cookie: JSESSIONID=xxxxxxxx 200 OK

Authentication Form

POST /oauth/token

Authorization: Basic: <client_id>:<secret> grant_type=authorization_code&code=<code >&redirect_uri=<uri>

200 OK { "token_type":"bearer", "access_token":“<access_token>", "expires_in":3600, "scope":“<scope>", "refresh_token":“<refresh_token>" } GET /resource

Authorization: Bearer <access_token> Check token

302 Processed

Set Cookie: JSESSIONID=yyyyyyyy

(16)

認証と許可が分離するパターン (1/2)



認証は既存の認証サーバーを使用することも可能



認証サーバーがリバース・プロキシーとして動作する場合

OAuthクライアント

・アプリケーション

ユーザー情報

認証サーバー

(リバース・プロキシー)

トークン失効管理

サーバー

リソース

アプリケーション・

サーバー

リソース・サーバー

リソース・オーナー

モバイル・アプリ

ブラウザー

IBM DataPower

Gateway (IDG)

許可サーバー・

エンドポイント

リソース・サーバー

適用ポイント

※認証後はパススルー

(17)

認証と許可が分離するパターン (2/2)



認証は既存の認証サーバーを使用することも可能



IDGがゲートウェイとして動作する場合

OAuthクライアント

・アプリケーション

ユーザー情報

認証サーバー

トークン失効管理

サーバー

リソース

アプリケーション・

サーバー

リソース・サーバー

リソース・オーナー

モバイル・アプリ

ブラウザー

IBM DataPower

Gateway (IDG)

許可サーバー・

エンドポイント

リソース・サーバー

適用ポイント

(18)

IDGの冗長構成について



OAuthを使用する場合のIDGの冗長構成



複数台のIDGでActive-Active構成が可能



許可コードやトークンに必要な情報が含まれるため、セッション維持の必

要はない



許可コードやトークンに含まれる有効期限情報で有効/無効を判断するため、

すべてのIDGで時刻設定を合わせる必要がある



NTPを使用するなど



当方で検証した限りでは、使用済みの許可フォームや許可コード、リフ

レッシュ・トークンを再利用できないようにするために、IDGでは情報を

内部にキャッシュすることを確認した。複数台で冗長構成とする場合、

キャッシュを共有できないため、IDG台数分は許可フォーム/許可コード/リ

フレッシュ・トークンが再利用できてしまう可能性がある。



キャッシュは「状況」>「暗号」>「OAuthキャッシュ」より確認可能



キャッシュの説明については当資料「IDG内部キャッシュの利用 (2/3)」を参照

(19)

(20)

OAuth構成方法



OAuthプロトコルを使用するためには、AAAポリシーを構成する必要が

あり、下表のいずれかの方法で構成可能



構成方法によりサポートされるOAuthロールが異なる

※当資料では、MPGを使用する場合の構成手順を記載します

構成方法

サポートされるOAuthロール

Webトークン・サービス (WTS)

許可サーバー・エンドポイント

マルチプロトコル・ゲートウェイ (MPG)

許可サーバー・エンドポイント

リソース・サーバーの適用ポイント

(21)

OAuth構成手順概要 (1/2)



前提事項



クライアントからIDGへのアクセスはHTTPSを使用



SSL接続に必要な暗号鍵および証明書の設定が済んでいること



IDGにおける自己署名証明書の作成方法は、後述の「(参考) サーバー証明書および秘密鍵の作成」を参照



認証はIDG内で行い、Basic認証またはForm認証を使用



OAuthのグラント・タイプとして「許可コード」を使用



サンプルとしてリソース・サーバーもIDGを使用し、XML Firewallサービスにてリ

ソースを提供する



本資料で使用するXML Firewallサービスのサンプルは、下記リンク先で提供されるサンプル・

コードを元に作成



http://www.ibm.com/developerworks/apps/download/index.jsp?contentid=829237&filename=

AccountLoopback.zip&method=http&locale=



事前に上記サンプル・コードをIDGの任意のドメインにインポートし、更に以下の点を修正し

て使用



ポート番号を5071に変更

 「サービス」>「XMLファイアウォール」>「XMLファイアウオールの編集」より該当XML Firewallサービスを選択し、「一般」タブより設定変更 

「local:///json_response.xsl」内のリソース・オーナーを取得するヘッダー名を修正

修正前

<xsl:variable name="resource-owner" select="str:decode-uri(dp:http-request-header('ResourceOwner'))"/>

(22)

OAuth構成手順概要 (2/2)



構成手順概要

1. OAuthクライアントの登録

1.

OAuthクライアント・プロファイルの作成

2.

OAuthクライアント・グループの作成

2. AAAポリシー作成

1.

OAuth許可およびトークン・エンドポイント用 (Form認証用)

2.

OAuth許可およびトークン・エンドポイント用 (Basic認証用)

3.

リソース・サーバー適用ポイント用

3. AAAポリシーを使用してマルチプロトコル・ゲートウェイを構成

1.

マルチプロトコル・ゲートウェイの作成

2.

処理ポリシーの作成

1.

favicon用リクエスト・ルール

2.

Form認証およびOAuth許可用リクエスト・ルール

3.

Basic認証およびOAuth許可用リクエスト・ルール

4.

リソース・サーバー適用ポイント用リクエスト・ルール

5.

レスポンス・ルール

6.

エラー・ルール

3.

HTTPSフロント・サイド・ハンドラーの作成

(23)

(再掲) OAuth構成手順概要



構成手順概要

1. OAuthクライアントの登録

1.

OAuthクライアント・プロファイルの作成

2.

OAuthクライアント・グループの作成

2. AAAポリシー作成

1.

OAuth許可およびトークン・エンドポイント用 (Form認証用)

2.

OAuth許可およびトークン・エンドポイント用 (Basic認証用)

3.

リソース・サーバー適用ポイント用

3. AAAポリシーを使用してマルチプロトコル・ゲートウェイを構成

1.

マルチプロトコル・ゲートウェイの作成

2.

処理ポリシーの作成

1.

favicon用リクエスト・ルール

2.

Form認証およびOAuth許可用リクエスト・ルール

3.

Basic認証およびOAuth許可用リクエスト・ルール

4.

リソース・サーバー適用ポイント用リクエスト・ルール

5.

レスポンス・ルール

6.

エラー・ルール

3.

HTTPSフロント・サイド・ハンドラーの作成

(24)

1. OAuthクライアントの登録 (1/5)

1. OAuthクライアント・プロファイルの作成



メニューより、「オブジェクト」 > 「暗号構成」 > 「OAuthクライアン

ト・プロファイル」を選択し、新規作成

OAuthクライアント毎にロールを指定。

ここでは、両方にチェックを入れる。

サポートするグラント・タイプを指定。

ここでは、「許可コード」にチェック

を入れる。

(25)

1. OAuthクライアントの登録 (2/5)

1. OAuthクライアント・プロファイルの作成 (続き)

クライアント・タイプおよびクライアントの認証方式

を指定。

ここでは、クライアント・タイプを「機密」とし、ク

ライアント・シークレットで認証する。

※クライアント・シークレットを明示的に定義する場

合、事前に「クライアント・シークレットの生成」欄

のチェックを外す必要があります。

スコープを正規表現 (PCRE)で指定。

ここでは、「/getAccountInfo」または

「/getCustomerInfo」を許可する

「^/getAccountInfo|/getCustomerInfo」を入力。

トークン保護のための共有秘密鍵を指定。(次頁参照)

クライアントに許可コードのトークンを渡すためのリ

ダイレクトURLを指定。 (複数指定可能)

ここでは、正規表現でHTTPSのすべてのURIに合致

する「https://{1}¥S+」を指定。

リソース・オーナーに送信する許可フォームを生成す

るためのXSLTを指定。

ここでは、OAuth用にデフォルトで提供されるXSLT

(26)

(参考) OAuthクライアントの共有秘密鍵



IDGで発行するトークンを暗号化するために使用する秘密鍵



32バイト以上の任意の16進数



共有秘密鍵の例：



sharedSecretKey.txt

0x1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF

(27)

1. OAuthクライアントの登録 (3/5)

1. OAuthクライアント・プロファイルの作成 (続き)

リクエストにスコープが指定されていない

場合のデフォルト値。

許可フォームの有効期間 (1～600秒/デ

フォルト値:300)。

許可コードの有効期間 (1～600秒/デフォ

ルト値:300)。

アクセス・トークンの有効期間 (1～

キャッシュ方式の指定。

ここでは、デフォルトの「リプレイのみ」

を選択。

OAuth処理エラーとしてクライアントに詳

細なエラーを返答するかどうかの指定 (デ

フォルトはチェックなし) 。

チェックを入れるとOAuthエラー応答に詳

細情報が含まれる。

(28)

1. OAuthクライアントの登録 (4/5)

1. OAuthクライアント・プロファイルの作成 (続き)

IDGが生成できるリフレッシュ・トー

クンの総数 (0～2048個/デフォルト

値:0)

リフレッシュ・トークンの有効期間 (1

～2682000秒/デフォルト値:5400)

リソース・サーバーに対してヘッダー

で情報を付加するかどうかの指定。

ここでは、すべてにチェックを入れる。

(29)

1. OAuthクライアントの登録 (5/5)

2. OAuthクライアント・グループの作成



メニューより、「オブジェクト」 > 「暗号構成」 > 「OAuthクライアン

ト・グループ」を選択し、新規作成

グループ内のOAuthロールを指定。

ここでは、両方にチェックを入れる。

OAuthクライアントを選択。

(30)

(再掲) OAuth構成手順概要



構成手順概要

1. OAuthクライアントの登録

1.

OAuthクライアント・プロファイルの作成

2.

OAuthクライアント・グループの作成

2. AAAポリシー作成

1.

OAuth許可およびトークン・エンドポイント用 (Form認証用)

2.

OAuth許可およびトークン・エンドポイント用 (Basic認証用)

3.

リソース・サーバー適用ポイント用

3. AAAポリシーを使用してマルチプロトコル・ゲートウェイを構成

1.

マルチプロトコル・ゲートウェイの作成

2.

処理ポリシーの作成

1.

favicon用リクエスト・ルール

2.

Form認証およびOAuth許可用リクエスト・ルール

3.

Basic認証およびOAuth許可用リクエスト・ルール

4.

リソース・サーバー適用ポイント用リクエスト・ルール

5.

レスポンス・ルール

6.

エラー・ルール

3.

HTTPSフロント・サイド・ハンドラーの作成

(31)

2. AAAポリシー作成 (1/13)

1. OAuth許可およびトークン・エンドポイント用AAAポリシー (Form認

証用) (OAuth_AZ_Form)



メニューより、「オブジェクト」 >

「XML処理」 > 「AAAポリシー」を

選択し、フォーム認証用AAAポリシー

を新規作成

ID抽出方法を指定。

「HTMLフォーム・ベース認証」および

「OAuth」にチェックを入れる。

ログインフォームを指定。

ここでは、「OAuth_HTMLForm」

を新規作成。

デフォルトで提供され

るHTMLフォームを使用。

前手順で作成したOAuthクラ

イアント・グループを指定。

(32)

2. AAAポリシー作成 (2/13)

1. OAuth許可およびトークン・エンドポイント用AAAポリシー (Form認

証用) (OAuth_AZ_Form) (続き)

認証方式を指定。

ここでは、「AAA情報ファイルの使用」

を選択し、ファイルを指定する。

(ファイル例は次頁参照。)

(33)

2. AAAポリシー作成 (3/13)



AAA情報ファイル (OAuth_AAAInfo.xml)



IDGローカルにデフォルトで提供される「store:///AAAInfo.xml」を編集

して使用

<?xml version="1.0" encoding="utf-8"?>

<AAAInfo xmlns="http://www.datapower.com/AAAInfo">

<FormatVersion>1</FormatVersion>

<Filename>local:///xml/OAuth_AAAInfo.xml</Filename>

<Summary>This is an example of the file format.</Summary>

<Authenticate>

<Username>user01</Username>

<Password>password</Password>

<OutputCredential>USER01</OutputCredential>

</Authenticate>

<Authenticate>

<Username>user02</Username>

<Password>password</Password>

<OutputCredential>USER02</OutputCredential>

</Authenticate>

</AAAInfo>

OutputCredentialがリソース・オーナーとなる

(34)

2. AAAポリシー作成 (4/13)

1. OAuth許可およびトークン・エンドポイント用AAAポリシー (Form認

証用) (OAuth_AZ_Form) (続き)

リソース抽出方法を指定。

「処理メタデータ」を選択し、デフォルト

で提供される「oauth-scope-metadata」

を指定する。

(35)

2. AAAポリシー作成 (5/13)

1. OAuth許可およびトークン・エンドポイント用AAAポリシー (Form認

証用) (OAuth_AZ_Form) (続き)

許可方式を指定。

ここでは許可制御をしないため、「すべて

の認証クライアントを許可」を選択する。

(36)

2. AAAポリシー作成 (6/13)

2. OAuth許可およびトークン・エンドポイント用AAAポリシー (Basic認

証用) (OAuth_AZ_Basic)



メニューより、「オブジェクト」

> 「XML処理」 > 「AAAポリシ

ー」を選択し、OAuth許可および

トークン・エンドポイント用AAA

ポリシーを新規作成

ID抽出方法を指定。

「HTTP認証ヘッダー」および

「OAuth」にチェックを入れる。

ID抽出方法を指定。

「HTTP認証ヘッダー」および

「OAuth」にチェックを入れる。

前手順で作成したOAuthクラ

イアント・グループを指定。

(37)

2. AAAポリシー作成 (7/13)

2. OAuth許可およびトークン・エンドポイント用AAAポリシー (Basic認

証用) (OAuth_AZ_Basic) (続き)

認証方式を指定。

ここでは、「AAA情報ファイルの使用」を選択し、

作成した「OAuth_AAAInfo.xml」を指定。

(38)

2. AAAポリシー作成 (8/13)

2. OAuth許可およびトークン・エンドポイント用AAAポリシー (Basic認

証用) (OAuth_AZ_Basic) (続き)

リソース抽出方法を指定。

「処理メタデータ」を選択し、デフォルト

で提供される「oauth-scope-metadata」

を指定する。

(39)

2. AAAポリシー作成 (9/13)

2. OAuth許可およびトークン・エンドポイント用AAAポリシー (Basic認

証用) (OAuth_AZ_Basic) (続き)

許可方式を指定。

前フェーズにてスコープ検査を行っているため、

「すべての認証クライアントを許可」を選択する。

(40)

2. AAAポリシー作成 (10/13)

3. リソース・サーバー適用ポイント用AAAポリシー (OAuth_RS)



メニューより、「オブジェクト

」 > 「XML処理」 > 「AAA

ポリシー」を選択し、リソー

ス・サーバー適用ポイント用

AAAポリシーを新規作成

ID抽出方法を指定。

「OAuth」にチェックを入れる。

前手順で作成したOAuthクラ

イアント・グループを指定。

(41)

2. AAAポリシー作成 (11/13)

3. リソース・サーバー適用ポイント用AAAポリシー (OAuth_RS) (続き)

認証方式を指定。

「ID抽出」フェーズでトークンによるリク

エスト検査を行っているため、「許可

フェーズにIDトークンを渡す」を選択する。

(42)

2. AAAポリシー作成 (12/13)

3. リソース・サーバー適用ポイント用AAAポリシー (OAuth_RS) (続き)

リソース抽出方法を指定。

「クライアントにより送信されたURL」と

「処理メタデータ」を選択し、デフォルト

で提供される「oauth-scope-metadata」

を指定する。

(43)

2. AAAポリシー作成 (13/13)

3. リソース・サーバー適用ポイント用AAAポリシー (OAuth_RS) (続き)

許可方式を指定。

前フェーズにてトークン検査を行っているため、

「すべての認証クライアントを許可」を選択する。

(44)

(再掲) OAuth構成手順概要



構成手順概要

1. OAuthクライアントの登録

1.

OAuthクライアント・プロファイルの作成

2.

OAuthクライアント・グループの作成

2. AAAポリシー作成

1.

OAuth許可およびトークン・エンドポイント用 (Form認証用)

2.

OAuth許可およびトークン・エンドポイント用 (Basic認証用)

3.

リソース・サーバー適用ポイント用

3. AAAポリシーを使用してマルチプロトコル・ゲートウェイを構成

1.

マルチプロトコル・ゲートウェイの作成

2.

処理ポリシーの作成

1.

favicon用リクエスト・ルール

2.

Form認証およびOAuth許可用リクエスト・ルール

3.

Basic認証およびOAuth許可用リクエスト・ルール

4.

リソース・サーバー適用ポイント用リクエスト・ルール

5.

レスポンス・ルール

6.

エラー・ルール

3.

HTTPSフロント・サイド・ハンドラーの作成

(45)

3. マルチプロトコル・ゲートウェイを構成 (1/11)

1. マルチプロトコル・ゲートウェイの作成 (OAuthMPG)



メニューより、「コントロール・パネル」 > 「マルチプロトコル・ゲート

ウェイ」を選択して作成

ここでは、バックエンドのサービスとしてXML Firewallを

使用するため、「静的バックエンド」を選択し、URLとし

ここでは、バックエンドのサービスとしてXML Firewallを

使用するため、「静的バックエンド」を選択し、URLとし

⇒「2. 処理ポリシーの作成」へ

⇒「3. HTTPSフロント・サ

イド・ハンドラーの作成」へ

(46)

3. マルチプロトコル・ゲートウェイを構成 (2/11)

1. マルチプロトコル・ゲートウェイの作成 (OAuthMPG) (続き)

バックエンド・システムとHTTPSで通信する場合は、

SSLクライアント・プロファイルを構成する。

ここでは、バックエンドへのアクセスはHTTPを使

用するため省略。

応答タイプの指定。

ここでは、「非XML」を選択。

要求タイプの指定。

ここでは、「非XML」を選択。

(47)

2. 処理ポリシーの作成 (OAuthPolicy)

1. favicon用リクエスト・ルール (OAuthPolicy_rule_favicon)



「favicon.ico」に対するリクエストについては、何もせずにそのままバックエンドへ送信する

3. マルチプロトコル・ゲートウェイを構成 (3/11)

「結果」アクション

「マッチング」アクション

「クライアントからサーバー」を選択。

(48)

2. 処理ポリシーの作成 (OAuthPolicy) (続き)

2. Form認証およびOAuth許可用リクエスト・ルール (OAuthPolicy_rule_az_form)



Form認証を実施し、OAuth許可処理を行うルール

3. マルチプロトコル・ゲートウェイを構成 (4/11)

「マッチング」アクション

「結果」アクション

「クライアントからサーバー」を選択。

「照会パラメーターをXML

に変換する」アクション

(設定はデフォルト)

_{「AAA」アクション}

(AAAポリシー「OAuth_AZ_Form」

を指定。)

(49)

2. 処理ポリシーの作成 (OAuthPolicy) (続き)

3. Basic認証およびOAuth許可用リクエスト・ルール (OAuthPolicy_rule_az_basic)



Basic認証を実施し、OAuth許可処理を行うルール

3. マルチプロトコル・ゲートウェイを構成 (5/11)

「照会パラメーターをXML

に変換する」アクション

(設定はデフォルト)

「マッチング」アクション

「クライアントからサーバー」を選択。

「結果」アクション

「AAA」アクション

(AAAポリシー「OAuth_AZ_Basic」

を指定。)

(50)

2. 処理ポリシーの作成 (OAuthPolicy) (続き)

4. リソース・サーバー適用ポイント用リクエスト・ルール (OAuthPolicy_rule_rs)



アクセス・トークン検査を行うルール

3. マルチプロトコル・ゲートウェイを構成 (6/11)

「マッチング」アクション

「結果」アクション

「AAA」アクション

(AAAポリシー「OAuth_RS」

を指定。)

「クライアントからサーバー」を選択。

「照会パラメーターをXML

に変換する」アクション

(設定はデフォルト)

(51)

3. マルチプロトコル・ゲートウェイを構成 (7/11)

2. 処理ポリシーの作成 (OAuthPolicy) (続き)

5. レスポンス・ルール (OAuthPolicy_rule_response)



ここでは、レスポンスに対する処理は何も実施しない

「サーバーからクライアント」を選択。

「マッチング」アクション

「結果」アクション

(52)

2. 処理ポリシーの作成 (OAuthPolicy) (続き)

6. エラー・ルール (OAuthPolicy_rule_error)



処理ルール内のエラー時に、エラー・メッセージをJSON形式へ変換する処理を実施

3. マルチプロトコル・ゲートウェイを構成 (8/11)

「エラー」を選択。

「マッチング」アクション

「変換」アクション

「結果」アクション

XSLTスタイルシートを作成し、IDG

ローカルにアップロード。 (次頁参照)

「XSLTスタイルシートを使用

して変換する」を選択。

デフォルト (エラー・ルールがない場合)

は、処理エラーがSOAP/XMLになります。

「フェッチ」アクション

任意のXMLファイルを作成し、

IDGローカルにアップロード。

dummy.xmlの例： <a>dummy</a>

(53)

3. マルチプロトコル・ゲートウェイを構成 (9/11)



XSLTスタイルシート (error.xsl)



エラー・メッセージ (サービス変数：error-message)をJSON形式で出力

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:dp="http://www.datapower.com/extensions" extension-element-prefixes="dp" exclude-result-prefixes="dp">

<xsl:output method="text" encoding="utf-8" indent="no" media-type="application/json"/> <xsl:template match="/">

<xsl:text>{"errorMsg" : "</xsl:text><xsl:value-of select="dp:variable('var://service/error-message')"/><xsl:text>"}</xsl:text> </xsl:template>

(54)

(参考) バックエンド・エラーの処理



バックエンド・サーバーからエラー・コードを

受信した場合のIDGでの処理を設定可能



設定箇所



マルチプロトコル・ゲートウェイの「拡張」タブ

の「バックエンド・エラーの処理」



「オン」 (デフォルト)



レスポンス・ルールで処理する



「オフ」



エラー・ルールで処理し、処理が正常終了した場合、

クライアントにエラー・ルールで指定した応答コード

を返す



エラー・ルール内で「変換 (Transform)」アクション

などを使用してエラー・コードの扱いを定義する必要

がある

(55)

3. マルチプロトコル・ゲートウェイを構成 (10/11)

3. HTTPSフロント・サイド・ハンドラーの作成 (OAuthFSH)

リクエストを受け付けるポート番号を指定。

ここでは、「5070」を使用する。

デフォルトからGETメソッドを追加。

SSLサーバー設定 (次頁参照)

(56)

3. マルチプロトコル・ゲートウェイを構成 (11/11)

3. HTTPSフロント・サイド・ハンドラーの作成 (OAuthFSH) (続き)

秘密鍵を指定。

サーバー証明書を指定。

(57)



IDGにて自己署名証明書を生成可能



「管理」 > 「その他」 > 「暗号

ツール」

(58)



アクセス許可要求 (Basic認証)



Webブラウザーにて以下のURLにアクセス

https://<IDG_IPAddress>:5070/oauth/authz?response_type=code&client_i

d=OAuthClient01&redirect_uri=https://localhost&scope=/getAccountInfo

%20/getCustomerInfo&state=MyTest

実行結果例 (1/6)

リソース・オーナーは許可サーバー上のユーザー名/パスワードを入力して認証認証後、リソース・オーナーは許可するスコープを選択してSubmit 許可コード取得

(59)



アクセス許可要求 (Form認証)



Webブラウザーにて以下のURLにアクセス

https://<IDG_IPAddress>:5070/form/oauth/authz?response_type=code&cli

ent_id=OAuthClient01&redirect_uri=https://localhost&scope=/getAccoun

tInfo%20/getCustomerInfo&state=MyTest

実行結果例 (2/6)

リソース・オーナーは許可サーバー上のユーザー名/パスワードを入力して認証認証後、リソース・オーナーは許可するスコープを選択してSubmit 許可コード取得

(60)

実行結果例 (3/6)



アクセス・トークン発行



cURLにて以下のコマンドを実行

curl -k https://<IDG_IPAddress>:5070/oauth/token -d

"grant_type=authorization_code&code=<Authorization_Code>&redirect_ur

i=https://localhost" --user OAuthClient01:passw0rd



応答電文：

{ "token_type":"bearer",

"access_token":"AAENT0F1dGhDbGllbnQwMRGCj7LJVASb6cEx82JLcoSVw3qEgYXI

1W3340IktnooV02aDzKZ6mLFkV3x88HpPz17_GKlqSvN3SFcLJd3YR94GKM8tpp8omrs

-yTyQQGLgwUOZy_sz3n44XgPv4VAOQ", "expires_in":3600,

"scope":"/getAccountInfo /getCustomerInfo",

"refresh_token":"AAEHtq9c8-YLOKSkQaxgyIW0VQ1uQ-UF7FfEtLG8hf8sEckgbLTakJd8a1CgRP8O5dh1fcG05MIMv3qp53W_y6TpygthAtv87O

mdjLM_i5U23Kf828-qWaJXa_R_B8UONFQ" }

(61)

実行結果例 (4/6)



リソース・アクセス



cURLにて以下のコマンドを実行



/getAccountInfo

curl -k https://<IDG_IPAddress>:5070/getAccountInfo -H

"Authorization:Bearer <Access_Token>"



応答電文：

{ "name": "myAccount",

"balance":1.00

}



/getCustomerInfo

curl -k https://<IDG_IPAddress>:5070/getCustomerInfo -H

"Authorization:Bearer <Access_Token>"



応答電文：

[ { "id":0, "name":"USER01",

"access_token":"AAENT0F1dGhDbGllbnQwMRGCj7LJVASb6cEx82JLcoSVw3qEgYXI1W3340IktnooV

02aDzKZ6mLFkV3x88HpPz17_GKlqSvN3SFcLJd3YR94GKM8tpp8omrs-yTyQQGLgwUOZy_sz3n44XgPv4VAOQ" } ]

(62)

実行結果例 (5/6)



アクセス・トークンの検査



cURLにて以下のコマンドを実行

curl -k https://<IDG_IPAddress>:5070/oauth/token -d

"grant_type=urn:ibm:datapower:validate&access_token=<Access_Token>"

--user OAuthClient01:passw0rd



応答電文：



OK (トークンが有効な場合)

{ "valid":true, "token_type":"bearer", "client_id":"OAuthClient01",

"not_after":"133528131", "not_after_text":"2016-03-25T11:08:51Z",

"not_before":"133524531", "not_before_text":"2016-03-25T10:08:51Z",

"resource_owner":"USER01", "scope":"/getAccountInfo /getCustomerInfo" }



NG (トークンが期限切れの場合)

(63)

実行結果例 (6/6)



リフレッシュ・トークンによるアクセス・トークンの再発行



cURLにて以下のコマンドを実行

curl -k https://<IDG_IPAddress>:5070/oauth/token -d

"grant_type=refresh_token&refresh_token=<Refresh_Token>&scope=/getAc

countInfo%20/getCustomerInfo" --user OAuthClient01:passw0rd



応答電文：

{ "token_type":"bearer",

"access_token":"AAENT0F1dGhDbGllbnQwMX0mij_6CZvofVbL87RvVxhHPYOiNZiy

xpnm9eO-7Xz86MzeNw11_XBOYqTXezw5NobD_AIhV-OHeEN8pS1HhzEvZONpVSvXghHPzmXJVf9t-FAfy10UPasIawztAZH0xg",

"expires_in":3600, "scope":"/getAccountInfo /getCustomerInfo",

"refresh_token":"AAG6viMfP_kwEE0YObrBuWju0bFpV9fnOA-

1lQdBPjgBiESyKld0fSBO5iU2pAMr-jGcuGdW1BXd6Fe3jm5SeVWgsOToS4O1Pur6Ukq0BisnOtMqCR83lw92gp1LMNrBFvs"

}

(64)

(参考) バックエンド・サーバーへの情報連携



HTTPヘッダーにリソース・オーナー、クライアントID、スコープを付

加することが可能



OAuthクライアント・プロファイルの「拡張」タブ > 「HTTPヘッダーの作

成対象」にて設定

(65)

Tips：



許可コード



アクセストークン発行後は、同じ許可コードは有効期限内であっても再利用不可



ただし、冗長構成の場合は注意が必要です。詳細は当資料「IDGの冗長構成について」を参照

してください。



リフレッシュトークン



有効なアクセストークンがある場合でもリフレッシュトークンで新規アクセストーク

ンを発行可能。その際、古いアクセス・トークンは失効されない。



そのため、有効なアクセストークンが複数できてしまうことが考えられます。



アクセストークン再発行に使用したリフレッシュトークンは、有効期限内であっても

再利用不可。



ただし、冗長構成の場合は注意が必要です。詳細は当資料「IDGの冗長構成について」を参照

してください。



スコープ



IDGではスコープを厳密にチェックするため、正確に定義する必要がある。



例えば、許可スコープが「/getAccountInfo」の場合、「/getAccountInfo/xxxx」はスコー

プ検査により拒否される



許可スコープを「/getAccountInfo*」とすることで、「/getAccountInfo/xxxx」へのアクセ

スも許可される

(66)

エラー応答例 (1/7)



OAuth処理エラー



例：不正なresponse_typeが指定された場合



リクエスト

curl -i -k

"https://<IDG_IPAddress>:5070/oauth/authz?

response_type=test

&client_id=OA

uthClient01&redirect_uri=https://localhost&scope=/getAccountInfo%20/getCu

stomerInfo&state=MyTest" --user user01:password



レスポンス



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがない場合

302 Processed

Location: https://localhost?

error=unsupported_response_type

&state=MyTest



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがある場合

302 Processed

Location:https://localhost?

error=unsupported_response_type&error_descript

ion=Unsupported+response_type

&state=MyTest

OAuth処理エラーはOAuth 2.0の仕様に準拠したエラー・レスポンスとなります。

詳細エラー (error_description)を応答させたい場合は設定が必要です。(当資料「1.

OAuthクライアントの登録 (3/5)」を参照。)

(67)

エラー応答例 (2/7)



OAuth処理エラー (続き)



例：不正なスコープが指定された場合



リクエスト

curl -i -k

"https://<IDG_IPAddress>:5070/oauth/authz?response_type=code&client_id=OA

uthClient01&redirect_uri=https://localhost&

scope=/getResouce

&state=MyTest

" --user user01:password



レスポンス



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがない場合

302 Processed

Location: https://localhost?

error=invalid_scope

&state=MyTest



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがある場合

302 Processed

Location:

https://localhost?

error=invalid_scope&error_description=Invalid+or+unsupp

orted+scope

&state=MyTest

OAuth処理エラーはOAuth 2.0の仕様に準拠したエラー・レスポンスとなります。

詳細エラー (error_description)を応答させたい場合は設定が必要です。(当資料「1.

OAuthクライアントの登録 (3/5)」を参照。)

(68)

エラー応答例 (3/7)



OAuth処理エラー (続き)



例：不正なgrant_typeが指定された場合



リクエスト

curl -i -k https://<IDG_IPAddress>:5070/oauth/token -d

"

grant_type=test

&code=AAK9YRSPjG3TrpyJKYr1RQ93uh_YMlJVt79g1zHozdUwFHsLKXW

pNU7ffoxokAvoQJ10cwuFtPuM2RnPnuVH_Is_qMv8Ns9TLMwAm2-vJDbWCaF-ezS5l_9djFnmACUYNfY&redirect_uri=https://localhost" --user

OAuthClient01:passw0rd



レスポンス



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがない場合

400 Processed

{ "error":"unsupported_grant_type "}



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがある場合

400 Processed

{ "error":"unsupported_grant_type", "error_description":"grant_type or code not

supported" }

OAuth処理エラーはOAuth 2.0の仕様に準拠したエラー・レスポンスとなります。

詳細エラー (error_description)を応答させたい場合は設定が必要です。(当資料「1.

OAuthクライアントの登録 (3/5)」を参照。)

(69)

エラー応答例 (4/7)



OAuth処理エラー (続き)



例：クライアント認証失敗 (不正なクライアント・シークレット)



リクエスト

curl -i -k https://<IDG_IPAddress>:5070/oauth/token -d

"grant_type=authorization_code&code=AAKMMjbTa5zKfbhWN2nj1gmRoz5Fe07qFbSZd

Y6JYK8PuBcmwKvas9i0lDgkRilpqEtToKHUzNCDS674UOp6dLyV7XlmaU66EhCT-fchPi4XyjZNFT_ztQn2Lfy6gnpIJg8&redirect_uri=https://localhost" --user

OAuthClient01:

12345



レスポンス



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがない場合

401 Processed

{ "error":"invalid_client"}



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがある場合

401 Processed

{ "error":"invalid_client", "error_description":"Missing or invalid

client_secret" }

OAuth処理エラーはOAuth 2.0の仕様に準拠したエラー・レスポンスとなります。

詳細エラー (error_description)を応答させたい場合は設定が必要です。(当資料「1.

OAuthクライアントの登録 (3/5)」を参照。)

(70)

エラー応答例 (5/7)



OAuth処理エラー (続き)



例：許可コードの有効期限が切れている場合



リクエスト

curl -i -k https://<IDG_IPAddress>:5070/oauth/token -d

"grant_type=authorization_code&code=AAJO1PYnapEAYNDYftNZT3OiWk2eYoQj3RTjX

NIn6CTcX3lTOGwnzagALZsEAhb046if1rTL8GIaYaZyyjS0OplciatSSAExWkQ5mqgVGHhp83Tgx_WyWuXdAwMfXHSE&redirect_uri=https://localhost"

--user OAuthClient01:passw0rd



レスポンス



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがない場合

400 Processed

{ "error":"invalid_grant" }



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがある場合

400 Processed

{ "error":"invalid_grant", "error_description":"*[OAuthClient01] code

expired*" }

OAuth処理エラーはOAuth 2.0の仕様に準拠したエラー・レスポンスとなります。

詳細エラー (error_description)を応答させたい場合は設定が必要です。(当資料「1.

OAuthクライアントの登録 (3/5)」を参照。)

(71)

エラー応答例 (6/7)



OAuth処理エラー (続き)



例：アクセス・トークンの有効期限が切れている場合



リクエスト

curl -i -k https://<IDG_IPAddress>:5070/getCustomerInfo -H

"Authorization:Bearer

AAENT0F1dGhDbGllbnQwMSNTqk4K8nZ5fvO_D-H6KGZjX6BwQMKuqX_kN6uOEwvdyzmR_2887rMfod7VMaO3ulVOhjD1shPvtvID5MxzBPTY5tD

UVM5Hm7khv_sE_l-sZEx4d47Eig86dgUSntgOBA

“ 

レスポンス



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがない場合

401 Unauthorized

WWW-Authenticate: Bearer error="invalid_token"

{"errorMsg" : "Failed to verify OAuth information."}



OAuthクライアント・プロファイルの「詳細エラー」設定にチェックがある場合

401 Unauthorized

WWW-Authenticate: Bearer

error="invalid_token",error_description="*[OAuthClient01] access_token

expired*"

{"errorMsg" : "Failed to verify OAuth information."}

OAuth処理エラーはOAuth 2.0の仕様に準拠したエラー・レスポンスとなります。

詳細エラー (error_description)を応答させたい場合は設定が必要です。(当資料「1.

(72)

エラー応答例 (7/7)



IDG内部処理ルール・エラー



例：アクセス許可要求時に不正なクライアントIDが指定されている場合



リクエスト

curl -i -k

"https://<IDG_IPAddress>:5070/oauth/authz?response_type=code&

client_id=OA

uthClient99

&redirect_uri=https://localhost&scope=/getAccountInfo%20/getCu

stomerInfo&state=MyTest" --user user01:password



レスポンス

400 Error

{"errorMsg" : "Failed to verify OAuth information."}



例：不正なユーザーからのアクセス許可要求



リクエスト

curl -i -k

"https://9.188.255.85:5070/oauth/authz?response_type=code&client_id=OAuth

Client01&redirect_uri=https://localhost&scope=/getAccountInfo%20/getCusto

merInfo&state=MyTest" --user

user99

:password



レスポンス

401 Unauthorized

{"errorMsg" : "Rejected by policy."}

エラー電文はエラー・ルールにて定義したも

のです。(当資料「3. マルチプロトコル・

ゲートウェイを構成 (8-9/11)」を参照。)

(73)

(74)

OAuthプロセスのカスタマイズ (1/3)



IDGではXSLTまたはGatewayScriptを使用して、以下のOAuth処理のカスタマ

イズが可能



カスタマイズOAuthクライアント



XSLTまたはGatewayScriptにてロールおよび動作をより細かく定義可能



カスタム・スコープ検査



デフォルトでは、スコープ検査に正規表現を使用



カスタム・スコープ検査により、スコープ一覧を使用した検査などが可能



以下の場合に使用可能



許可要求時 (authorization_request)



アクセス・トークン要求時 (access_request)



リソース要求時 (resource_request)



許可フォームのカスタマイズ



リソース・オーナーが許可要求を事前承認するためのHTMLフォームのカスタマイズが可能



リソース所有者カスタム処理



デフォルトでは、IDGによってリソース・オーナーの資格情報が判別される



カスタム処理により、認証から取得したリソース・オーナーに関する情報をオーバーライド可

能



以下の場合に使用可能



リソース・オーナーに許可フォームを示す場合 (authorization_request)



許可コード発行する場合 (authorization_request)



アクセス・トークン発行する場合 (access_request)

(75)

OAuthプロセスのカスタマイズ (2/3)



IDGではXSLTまたはGatewayScriptを使用して、以下のOAuth処理の

カスタマイズが可能 (続き)



追加OAuth処理

OAuth処理 説明 authorization_form リソース・オーナーが許可フォームをIDGに返答後の処理のカスタマイズ。グラント・タイプが許可コードおよびインプリシットの場合に使用可能。 authorization_request 許可コード生成後の処理のカスタマイズ。 OAuthクライアントへ許可コード送信時に追加情報を付加可能。 access_request アクセス・トークンを生成してからOAuthクライアントへ送信するまでの間の処理のカスタマイズ。 OAuthクライアントへアクセス・トークン送信時にJOSNメッセージに追加情報を付加可能。 validate_request アクセス・トークン検査要求に対して、検査成功後の処理のカスタマイズ。 OAuthクライアントへの検査結果応答時のJSONメッセージに追加情報を付加可能。 resource_request リソース要求に対して、アクセス・トークン検査成功後の処理のカスタマイズ。リソース・サーバーに対するリクエストにHTTPヘッダーなど追加情報 (例えばリソース・オーナーのID 情報など)を付加可能。 revoke_request トークン失効要求を受信した際の処理のカスタマイズ。 check_revocation_request トークン検査時に失効チェックを実施することが可能。 preapproved_check リソース・オーナーが許可要求を事前承認するか、事前拒否するか、許可フォームを表示するかの検査。許可フォームのバイパスが可能。グラント・タイプが許可コードおよびインプリシットの場合に使用可能。 miscinfo_request 許可コードやトークンに追加情報 (最大512文字)を付与可能。許可サーバーは各種情報をトークンに追加し、OAuthクライアントへ応答する。

(76)

76

3. リソース所有者カスタム処理

OAuthプロセスのカスタマイズ (3/3)

IBM DataPower Gateway (IDG)

許可サーバー・エンドポイント＆

リソース・サーバー適用ポイント

リソース・オーナー

OAuthクライアント

リソース・サーバー

Basic Authentication Scope Accept Publish code

Check token アクセス・トークン 4. authorization_form処理認証アクセス許可要求アクセス・トークン発行要求リソース要求 5. authorization_request処理 6. access_request処理許可コード許可フォーム _{2. 許可フォームのカスタマイズ} 11. preapproved_check処理 Validate token アクセス・トークン検査要求 7. validate_request処理アクセス・トークン失効要求 Revoke token success 9. revoke_request処理カスタム・スコープ検査カスタム・スコープ検査 1. カスタム・スコープ検査 8. resource_request処理 miscinfo_request処理 10. check_revocation_request処理 3. リソース所有者カスタム処理 12. miscinfo_request処理

(77)

カスタム・スコープ検査 (1/5)



設定方法



OAuthクライアント・プロファイルにて設定



メニューより「オブジェクト」 > 「暗号構成」 > 「OAuthクライアント・プロ

ファイル」で、カスタマイズしたいプロファイルを選択表示し、「メイン」タブの

「カスタマイズ・スコープ検査」にチェックを入れる



「スコープ・カスタマイズ処理」にて作成したXSLT (またはGatewayScript)を指

定する



カスタマイズ・サンプル



許可要求に含まれるスコープが事前定義した許可スコープ一覧に合致してい

るかを検査し、合致しているスコープのみを許可フォームに表示する



実装方法



許可スコープ一覧の定義ファイル (OAuth_Scopes.xml)の作成



スコープ・カスタマイズ処理のXSLTファイル (dp-custom-validate-scope.xsl)の

1. カスタム・スコープ検査

(78)

カスタム・スコープ検査 (2/5)



許可スコープ一覧の定義ファイル (OAuth_Scopes.xml)

<?xml version="1.0" encoding="UTF-8"?>

<scopes>

<scope>/getAccountInfo</scope>

<scope>/getCustomerInfo</scope>

</scopes>

(79)

カスタム・スコープ検査 (3/5)



スコープ・カスタマイズ処理のXSLTファイル

(dp-custom-validate-scope.xsl)

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"

xmlns:dp="http://www.datapower.com/extensions"

xmlns:dpconfig="http://www.datapower.com/param/config"

xmlns:dpfunc="http://www.datapower.com/extensions/functions"

xmlns:str="http://exslt.org/strings"

xmlns:regexp="http://exslt.org/regular-expressions"

extension-element-prefixes="dp dpfunc"

exclude-result-prefixes="dp dpfunc dpconfig str regexp">

<xsl:template match="/">

<xsl:variable name="props">

<xsl:copy-of select="document(concat('local:///xml/OAuth_Scopes.xml'))"/>

</xsl:variable>

<xsl:if test="string($props) = ''">

<dp:set-variable name="'var://context/error/errMsg'" value="concat('Error on loading Property XML File

(XMLName=OAuth_Scopes.xml)')" />

<dp:reject/>

<xsl:message dp:type="xslt" dp:priority="warn" terminate="yes" />

</xsl:if>

<xsl:variable name="translated-scope-from-url">

<xsl:value-of select="translate(/input/scope, '%20', ' ')"/>

</xsl:variable>

許可スコープ定義ファイルの読み込み

リクエストのスコープの”%20”を半角ス

ペースに変換 (Form認証用)

(80)

IBM DataPower Gateway (IDG)

OAuth構成ガイド

Disclaimer



当資料の位置づけ



当資料は、IBM DataPower Gateway (IDG) におけるOAuth機能の概要と、実装方

法および考慮点をまとめたものです。



Firmware v7.2.0.2を前提としています。



注意事項



当資料に含まれる情報は可能な限り正確を期しておりますが、当資料に記載された内

容に関して何ら保証するものではありません。ここでの記載内容はあくまでも支援情

報であり、使用者の責任において取扱われるものとし、資料の内容によって受けたい

かなる損害に関して一切の保証をいたしません。



製品の新しいリリース、修正などによって動作／仕様が変わる可能性がありますので、

必ずマニュアル等で最新の情報をご確認ください。

目次



OAuth概要



OAuth構成要素



IDGにおけるOAuthプロトコルのサポート



OAuth構成トポロジー



IDGが認証・許可するパターン

OAuth処理フロー (Basic認証 / Form認証)



認証と許可が分離するパターン



IDGの冗長構成について



OAuth構成方法



OAuth構成手順概要および詳細



OAuthプロセスのカスタマイズ



カスタム・スコープ検査



許可フォームのカスタマイズ



リソース所有者カスタム処理



追加OAuth処理



トークン失効管理



IDGにおけるトークン失効方法



IDGにおけるトークン失効管理

IDG内部キャッシュの利用と考慮点

OAuth構成要素 (1/2)



リソース・オーナー（Resource Owner）



保護されたリソースへのアクセスを許可するエンティティー



人間の場合はエンド・ユーザーに相当



OAuthクライアント（Client）



リソース・オーナーの許可を得て、リソース・オーナーの代理として保護されたリソー

スに対するリクエストを行うアプリケーション



アクセス・トークンを使用して保護されたリソースにアクセスする



許可サーバー（Authorization Server）



リソース・オーナーの認証とリソース・オーナーからの許可取得が成功した後、アクセ

ス・トークンをクライアントに発行するサーバー



リソース・サーバーと同一サーバーの場合と異なるサーバーの場合がある



リソース・サーバー（Resource Server）