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

Transcription

1 IBM DataPower Gateway (IDG) OAuth 構成ガイド

2 Disclaimer 当資料の位置づけ 当資料は IBM DataPower Gateway (IDG) における OAuth 機能の概要と 実装方法および考慮点をまとめたものです Firmware v を前提としています 注意事項 当資料に含まれる情報は可能な限り正確を期しておりますが 当資料に記載された内容に関して何ら保証するものではありません ここでの記載内容はあくまでも支援情報であり 使用者の責任において取扱われるものとし 資料の内容によって受けたいかなる損害に関して一切の保証をいたしません 製品の新しいリリース 修正などによって動作 / 仕様が変わる可能性がありますので 必ずマニュアル等で最新の情報をご確認ください 2

3 目次 OAuth 概要 OAuth 構成要素 IDG における OAuth プロトコルのサポート OAuth 構成トポロジー IDG が認証 許可するパターン OAuth 処理フロー (Basic 認証 / Form 認証 ) 認証と許可が分離するパターン IDG の冗長構成について OAuth 構成方法 OAuth 構成手順概要および詳細 OAuth プロセスのカスタマイズ カスタム スコープ検査 許可フォームのカスタマイズ リソース所有者カスタム処理 追加 OAuth 処理 トークン失効管理 IDG におけるトークン失効方法 IDG におけるトークン失効管理 IDG 内部キャッシュの利用と考慮点 外部リポジトリーの利用と考慮点 3

4 OAuth 概要 4

5 OAuth 構成要素 (1/2) リソース オーナー (Resource Owner) 保護されたリソースへのアクセスを許可するエンティティー 人間の場合はエンド ユーザーに相当 OAuth の詳細については RFC 6749 を参照 OAuth クライアント (Client) リソース オーナーの許可を得て リソース オーナーの代理として保護されたリソースに対するリクエストを行うアプリケーション アクセス トークンを使用して保護されたリソースにアクセスする 許可サーバー (Authorization Server) リソース オーナーの認証とリソース オーナーからの許可取得が成功した後 アクセス トークンをクライアントに発行するサーバー リソース サーバーと同一サーバーの場合と異なるサーバーの場合がある リソース サーバー (Resource Server) 保護されたリソースをホストし 保護されたリソースへのリクエストを受理してレスポンスを返すサーバー RFC6749 の日本語訳では Authorization server は 認可サーバー Authorization Code は 認可コード と記述されていますが 本製品の製品マニュアル KnowledgeCenter の日本語訳では 許可サーバー 許可コード と訳されており 本資料中でもその記述を踏襲します あらかじめご了承ください 5

6 OAuth 構成要素 (2/2) アクセス トークン OAuth の詳細については RFC 6749 を参照 リソース オーナーの保護リソースにアクセスするためのクレデンシャル OAuthクライアントが保護リソースへアクセスする際にリソース サーバーに送信する リフレッシュ トークン アクセス トークンを取得するためのクレデンシャル アクセス トークンの期限が切れた場合に 許可サーバーから新規アクセス トークンを要求したり 同一スコープまたはより狭いスコープを持つアクセス トークンを要求するために使用 リソース サーバーには送信されない 6

7 IDG における OAuth プロトコルのサポート (1/5) IDG は OAuth 2.0 をサポート 厳密には RFC6749 The OAuth 2.0 Authorization Framework のドラフト版 (draft-ietf-oauth-v2-31) がベース プロトコルフロー IDG は 2 者間フローと 3 者間フローをサポート 7

8 IDG における OAuth プロトコルのサポート (2/5) 2 者間フロー 以下のいずれかの場合に使用可能 OAuthクライアント = リソース オーナー OAuthクライアントが信頼できる ( リソース オーナーの資格情報を知っている ) 以下のグラント タイプが使用可能 リソース オーナー パスワード クレデンシャル クライアント クレデンシャル リソース オーナー & OAuth クライアント 許可サーバー リソース サーバー アクセス許可要求 認証 / 許可 w/ リソース オーナー資格情報 アクセス トークン (+ リフレッシュ トークン ) リソース アクセス w/ アクセス トークン アクセス トークン再発行要求 w/ リフレッシュ トークン アクセス トークン 8

9 IDG における OAuth プロトコルのサポート (3/5) 3 者間フロー リソース オーナーの資格情報を OAuth クライアントに知らせることなく OAuth クライアントがリソース サーバーによって保護されたリソースへアクセスすることを許可することが可能 許可コード ( または暗黙的付与 ) のグラント タイプを使用 リソース オーナー OAuth クライアント 許可サーバー リソース サーバー Initiate アクセス許可要求 (302 リダイレクト ) 認証 / 許可 w/ リソース オーナー資格情報 許可コード (302 リダイレクト ) アクセス トークン発行要求 w/ 許可コード + OAuth クライアント資格情報 アクセス トークン (+ リフレッシュ トークン ) リソース アクセス w/ アクセス トークン アクセス トークン再発行要求 w/ リフレッシュ トークン アクセス トークン 9

10 IDG における OAuth プロトコルのサポート (4/5) 以下の OAuth クライアントのロールのいずれかまたは両方をサポート 許可サーバー エンドポイント ( 許可エンドポイントおよびトークン エンドポイント ) IDG は保護されたリソースへのアクセス許可をリソース オーナーから取得し OAuth クライアントに対してアクセス トークンを発行する リソース サーバーの適用ポイント IDG はサービス提供者が保持するリソースを保護し OAuth クライアントが保護されたリソースへアクセスするための要求に対して応答する アクセス トークンを使用して要求の受け入れ可否を判断する ロールは OAuth クライアント プロファイル にて指定 同じ OAuth クライアント グループに属するすべての OAuth クライアント プロファイルは 同じロールまたはグループ内で定義されたロールのサブセットを持っている必要がある 10

11 IDG における OAuth プロトコルのサポート (5/5) OAuth ロールが許可サーバー エンドポイントの場合 グラント タイプの指定が必要 以下のグラント タイプをサポート 許可コード OAuth クライアントは許可コードによってアクセス許可を取得する 3 者間フローでのみ使用可能 暗黙的付与 (Implicit) OAuth クライアントはアクセス トークンを取得する際に用いられる仲介のクレデンシャルを利用せず (= 暗黙 ) 直接アクセス トークンを取得する 3 者間フローでのみ使用可能 リソース オーナー パスワード クレデンシャル OAuth クライアントはリソース オーナーのパスワード クレデンシャルを使用してアクセス許可を取得する 2 者間フローでのみ使用可能 クライアント クレデンシャル クライアントのクレデンシャルを使用してアクセス許可を取得する 2 者間フローでのみ使用可能 JSON Web Token (JWT) JWT を使用してアクセス許可を取得する 2 者間フローでのみ使用可能 OpenID Connect (OIDC) 上記グラント タイプの一部として OIDC をサポート 11

12 OAuth 構成トポロジー 12

13 IDG が認証 許可するパターン IDG にて認証および OAuth 許可を行うことが可能 リソース オーナー モバイル アプリ ブラウザー ユーザー情報 リソース OAuth クライアント アプリケーション IBM DataPower Gateway (IDG) 認証サーバー 許可サーバー エンドポイント リソース サーバー適用ポイント アプリケーション サーバー リソース サーバー トークン失効管理サーバー トークン失効情報 13

14 OAuth 処理フロー (Basic 認証 & 許可コード ) IBM DataPower Gateway (IDG) リソース オーナー OAuth クライアント 許可サーバー エンドポイント & リソース サーバー適用ポイント リソース サーバー POST /oauth_request 302 Found Location: /oauth/authz?response_type=code&client_id=<client> &redirect_uri=<uri>&scope=<scope>&state=<state> 401 Unauthorized WWW-Authenticate: Basic realm=login Scope Accept Authorization: Basic: <username>:<password> GET /oauth/authz?response_type=code&client_id=<client>& redirect_uri=<uri>&scope=<scope>&state=<state> POST /oauth/authz selectedscope=<scope>&dp-state=<ticket>& resourceowner=<owner>&redirect_uri=<uri>&scope=<scope> &client_id=<client_id>&approve=true& Basic Authentication Authorization Form 200 OK Publish code POST /oauth/token Authorization: Basic: <client_id>:<secret> grant_type=authorization_code&code=<code >&redirect_uri=<uri> 302 Processed Location: <uri>?code=<code>&state=<state> { "token_type":"bearer", "access_token": <access_token>", "expires_in":3600, "scope": <scope>", "refresh_token": <refresh_token>" } Validate code & Publish token 200 OK GET /resource Authorization: Bearer <access_token> Check token 14

15 OAuth 処理フロー (Form 認証 & 許可コード ) IBM DataPower Gateway (IDG) リソース オーナー OAuth クライアント 許可サーバー エンドポイント & リソース サーバー適用ポイント リソース サーバー POST /oauth_request 302 Found Location: /form/oauth/authz?response_type=code&client_id=<clien t>&redirect_uri=<uri>&scope=<scope>&state=<state> Authentication Form 200 OK Scope Accept 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> POST /form/oauth/authz selectedscope=<scope>&dp-state=<ticket>& resourceowner=<owner>&redirect_uri=<uri>&scope=<scope> &client_id=<client_id>&approve=true& Authorization Form Form Authentication Publish code 200 OK Set Cookie: JSESSIONID=xxxxxxxx POST /oauth/token Authorization: Basic: <client_id>:<secret> grant_type=authorization_code&code=<code >&redirect_uri=<uri> 302 Processed Set Cookie: JSESSIONID=yyyyyyyy Location: <uri>?code=<code>&state=<state> { "token_type":"bearer", "access_token": <access_token>", "expires_in":3600, "scope": <scope>", "refresh_token": <refresh_token>" } Validate code & Publish token 200 OK GET /resource Authorization: Bearer <access_token> Check token 15

16 認証と許可が分離するパターン (1/2) 認証は既存の認証サーバーを使用することも可能 認証サーバーがリバース プロキシーとして動作する場合 リソース オーナー モバイル アプリ ブラウザー ユーザー情報 リソース OAuth クライアント アプリケーション 認証サーバー ( リバース プロキシー ) 認証後はパススルー IBM DataPower Gateway (IDG) 許可サーバー エンドポイント リソース サーバー適用ポイント アプリケーション サーバー リソース サーバー トークン失効管理サーバー トークン失効情報 16

17 認証と許可が分離するパターン (2/2) 認証は既存の認証サーバーを使用することも可能 IDG がゲートウェイとして動作する場合 リソース オーナー モバイル アプリ ブラウザー 認証サーバー ユーザー情報 リソース OAuth クライアント アプリケーション IBM DataPower Gateway (IDG) 許可サーバー エンドポイント リソース サーバー適用ポイント アプリケーション サーバー リソース サーバー トークン失効管理サーバー トークン失効情報 17

18 IDG の冗長構成について OAuth を使用する場合の IDG の冗長構成 複数台の IDG で Active-Active 構成が可能 許可コードやトークンに必要な情報が含まれるため セッション維持の必要はない 許可コードやトークンに含まれる有効期限情報で有効 / 無効を判断するため すべての IDG で時刻設定を合わせる必要がある NTP を使用するなど 当方で検証した限りでは 使用済みの許可フォームや許可コード リフレッシュ トークンを再利用できないようにするために IDG では情報を内部にキャッシュすることを確認した 複数台で冗長構成とする場合 キャッシュを共有できないため IDG 台数分は許可フォーム / 許可コード / リフレッシュ トークンが再利用できてしまう可能性がある キャッシュは 状況 > 暗号 > OAuth キャッシュ より確認可能 キャッシュの説明については当資料 IDG 内部キャッシュの利用 (2/3) を参照 18

19 OAuth 構成方法 19

20 OAuth 構成方法 OAuth プロトコルを使用するためには AAA ポリシーを構成する必要があり 下表のいずれかの方法で構成可能 構成方法によりサポートされる OAuth ロールが異なる 構成方法 Web トークン サービス (WTS) マルチプロトコル ゲートウェイ (MPG) サポートされる OAuth ロール 許可サーバー エンドポイント 許可サーバー エンドポイントリソース サーバーの適用ポイント 当資料では MPG を使用する場合の構成手順を記載します 20

21 OAuth 構成手順概要 (1/2) 前提事項 クライアントから IDG へのアクセスは HTTPS を使用 SSL 接続に必要な暗号鍵および証明書の設定が済んでいること IDG における自己署名証明書の作成方法は 後述の ( 参考 ) サーバー証明書および秘密鍵の作成 を参照 認証は IDG 内で行い Basic 認証または Form 認証を使用 OAuth のグラント タイプとして 許可コード を使用 サンプルとしてリソース サーバーも IDG を使用し XML Firewall サービスにてリソースを提供する 本資料で使用する XML Firewall サービスのサンプルは 下記リンク先で提供されるサンプル コードを元に作成 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'))"/> 修正後 <xsl:variable name="resource-owner" select="str:decode-uri(dp:http-request-header('dp-owner'))"/> 21

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フロント サイド ハンドラーの作成 22

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フロント サイド ハンドラーの作成 23

24 1. OAuth クライアントの登録 (1/5) 1. OAuth クライアント プロファイルの作成 メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル を選択し 新規作成 OAuth クライアント毎にロールを指定 ここでは 両方にチェックを入れる サポートするグラント タイプを指定 ここでは 許可コード にチェックを入れる 24

25 1. OAuth クライアントの登録 (2/5) 1. OAuth クライアント プロファイルの作成 ( 続き ) クライアント タイプおよびクライアントの認証方式を指定 ここでは クライアント タイプを 機密 とし クライアント シークレットで認証する クライアント シークレットを明示的に定義する場合 事前に クライアント シークレットの生成 欄のチェックを外す必要があります スコープを正規表現 (PCRE) で指定 ここでは /getaccountinfo または /getcustomerinfo を許可する ^/getaccountinfo /getcustomerinfo を入力 トークン保護のための共有秘密鍵を指定 ( 次頁参照 ) クライアントに許可コードのトークンを渡すためのリダイレクト URL を指定 ( 複数指定可能 ) ここでは 正規表現で HTTPS のすべての URI に合致する S+ を指定 リソース オーナーに送信する許可フォームを生成するための XSLT を指定 ここでは OAuth 用にデフォルトで提供される XSLT を選択 25

26 ( 参考 ) OAuth クライアントの共有秘密鍵 IDGで発行するトークンを暗号化するために使用する秘密鍵 32バイト以上の任意の16 進数 共有秘密鍵の例 : sharedsecretkey.txt 0x ABCDEF ABCDEF ABCDEF ABCDEF 26

27 1. OAuth クライアントの登録 (3/5) 1. OAuth クライアント プロファイルの作成 ( 続き ) キャッシュ方式の指定 ここでは デフォルトの リプレイのみ を選択 OAuth 処理エラーとしてクライアントに詳細なエラーを返答するかどうかの指定 ( デフォルトはチェックなし ) チェックを入れると OAuth エラー応答に詳細情報が含まれる リクエストにスコープが指定されていない場合のデフォルト値 許可フォームの有効期間 (1~600 秒 / デフォルト値 :300) 許可コードの有効期間 (1~600 秒 / デフォルト値 :300) アクセス トークンの有効期間 (1~ 秒 / デフォルト値 :3600) 27

28 1. OAuth クライアントの登録 (4/5) 1. OAuth クライアント プロファイルの作成 ( 続き ) IDG が生成できるリフレッシュ トークンの総数 (0~2048 個 / デフォルト値 :0) リフレッシュ トークンの有効期間 (1 ~ 秒 / デフォルト値 :5400) リソース サーバーに対してヘッダーで情報を付加するかどうかの指定 ここでは すべてにチェックを入れる 28

29 1. OAuth クライアントの登録 (5/5) 2. OAuth クライアント グループの作成 メニューより オブジェクト > 暗号構成 > OAuth クライアント グループ を選択し 新規作成 グループ内の OAuth ロールを指定 ここでは 両方にチェックを入れる OAuth クライアントを選択 29

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フロント サイド ハンドラーの作成 30

31 2. AAA ポリシー作成 (1/13) 1. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Form 認証用 ) (OAuth_AZ_Form) メニューより オブジェクト > XML 処理 > AAA ポリシー を選択し フォーム認証用 AAA ポリシーを新規作成 ID 抽出方法を指定 HTML フォーム ベース認証 および OAuth にチェックを入れる デフォルトで提供される HTML フォームを使用 ログインフォームを指定 ここでは OAuth_HTMLForm を新規作成 前手順で作成した OAuth クライアント グループを指定 31

32 2. AAA ポリシー作成 (2/13) 1. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Form 認証用 ) (OAuth_AZ_Form) ( 続き ) 認証方式を指定 ここでは AAA 情報ファイルの使用 を選択し ファイルを指定する ( ファイル例は次頁参照 ) 32

33 2. AAA ポリシー作成 (3/13) AAA 情報ファイル (OAuth_AAAInfo.xml) IDG ローカルにデフォルトで提供される store:///aaainfo.xml を編集して使用 <?xml version="1.0" encoding="utf-8"?> <AAAInfo xmlns=" <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> OutputCredentialがリソース オーナーとなる <Authenticate> <Username>user02</Username> <Password>password</Password> <OutputCredential>USER02</OutputCredential> </Authenticate> </AAAInfo> 33

34 2. AAA ポリシー作成 (4/13) 1. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Form 認証用 ) (OAuth_AZ_Form) ( 続き ) リソース抽出方法を指定 処理メタデータ を選択し デフォルトで提供される oauth-scope-metadata を指定する 34

35 2. AAA ポリシー作成 (5/13) 1. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Form 認証用 ) (OAuth_AZ_Form) ( 続き ) 許可方式を指定 ここでは許可制御をしないため すべての認証クライアントを許可 を選択する 35

36 2. AAA ポリシー作成 (6/13) 2. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Basic 認証用 ) (OAuth_AZ_Basic) メニューより オブジェクト > XML 処理 > AAA ポリシー を選択し OAuth 許可およびトークン エンドポイント用 AAA ポリシーを新規作成 ID 抽出方法を指定 HTTP 認証ヘッダー および OAuth にチェックを入れる 前手順で作成した OAuth クライアント グループを指定 36

37 2. AAA ポリシー作成 (7/13) 2. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Basic 認証用 ) (OAuth_AZ_Basic) ( 続き ) 認証方式を指定 ここでは AAA 情報ファイルの使用 を選択し 作成した OAuth_AAAInfo.xml を指定 37

38 2. AAA ポリシー作成 (8/13) 2. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Basic 認証用 ) (OAuth_AZ_Basic) ( 続き ) リソース抽出方法を指定 処理メタデータ を選択し デフォルトで提供される oauth-scope-metadata を指定する 38

39 2. AAA ポリシー作成 (9/13) 2. OAuth 許可およびトークン エンドポイント用 AAA ポリシー (Basic 認証用 ) (OAuth_AZ_Basic) ( 続き ) 許可方式を指定 前フェーズにてスコープ検査を行っているため すべての認証クライアントを許可 を選択する 39

40 2. AAA ポリシー作成 (10/13) 3. リソース サーバー適用ポイント用 AAA ポリシー (OAuth_RS) メニューより オブジェクト > XML 処理 > AAA ポリシー を選択し リソース サーバー適用ポイント用 AAA ポリシーを新規作成 ID 抽出方法を指定 OAuth にチェックを入れる 前手順で作成した OAuth クライアント グループを指定 40

41 2. AAA ポリシー作成 (11/13) 3. リソース サーバー適用ポイント用 AAA ポリシー (OAuth_RS) ( 続き ) 認証方式を指定 ID 抽出 フェーズでトークンによるリクエスト検査を行っているため 許可フェーズに ID トークンを渡す を選択する 41

42 2. AAA ポリシー作成 (12/13) 3. リソース サーバー適用ポイント用 AAA ポリシー (OAuth_RS) ( 続き ) リソース抽出方法を指定 クライアントにより送信された URL と 処理メタデータ を選択し デフォルトで提供される oauth-scope-metadata を指定する 42

43 2. AAA ポリシー作成 (13/13) 3. リソース サーバー適用ポイント用 AAA ポリシー (OAuth_RS) ( 続き ) 許可方式を指定 前フェーズにてトークン検査を行っているため すべての認証クライアントを許可 を選択する 43

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フロント サイド ハンドラーの作成 44

45 3. マルチプロトコル ゲートウェイを構成 (1/11) 1. マルチプロトコル ゲートウェイの作成 (OAuthMPG) メニューより コントロール パネル > マルチプロトコル ゲートウェイ を選択して作成 2. 処理ポリシーの作成 へ 3. HTTPS フロント サイド ハンドラーの作成 へ ここでは バックエンドのサービスとして XML Firewall を使用するため 静的バックエンド を選択し URL としてループバックアドレスと XML Firewall のポートを指定 45

46 3. マルチプロトコル ゲートウェイを構成 (2/11) 1. マルチプロトコル ゲートウェイの作成 (OAuthMPG) ( 続き ) バックエンド システムと HTTPS で通信する場合は SSL クライアント プロファイルを構成する ここでは バックエンドへのアクセスは HTTP を使用するため省略 応答タイプの指定 ここでは 非 XML を選択 要求タイプの指定 ここでは 非 XML を選択 46

47 3. マルチプロトコル ゲートウェイを構成 (3/11) 2. 処理ポリシーの作成 (OAuthPolicy) 1. favicon 用リクエスト ルール (OAuthPolicy_rule_favicon) favicon.ico に対するリクエストについては 何もせずにそのままバックエンドへ送信する クライアントからサーバー を選択 マッチング アクション 結果 アクション 47

48 3. マルチプロトコル ゲートウェイを構成 (4/11) 2. 処理ポリシーの作成 (OAuthPolicy) ( 続き ) 2. Form 認証および OAuth 許可用リクエスト ルール (OAuthPolicy_rule_az_form) Form 認証を実施し OAuth 許可処理を行うルール クライアントからサーバー を選択 マッチング アクション 結果 アクション 照会パラメーターを XML に変換する アクション ( 設定はデフォルト ) AAA アクション (AAA ポリシー OAuth_AZ_Form を指定 ) 48

49 3. マルチプロトコル ゲートウェイを構成 (5/11) 2. 処理ポリシーの作成 (OAuthPolicy) ( 続き ) 3. Basic 認証および OAuth 許可用リクエスト ルール (OAuthPolicy_rule_az_basic) Basic 認証を実施し OAuth 許可処理を行うルール クライアントからサーバー を選択 マッチング アクション 結果 アクション 照会パラメーターを XML に変換する アクション ( 設定はデフォルト ) AAA アクション (AAA ポリシー OAuth_AZ_Basic を指定 ) 49

50 3. マルチプロトコル ゲートウェイを構成 (6/11) 2. 処理ポリシーの作成 (OAuthPolicy) ( 続き ) 4. リソース サーバー適用ポイント用リクエスト ルール (OAuthPolicy_rule_rs) アクセス トークン検査を行うルール クライアントからサーバー を選択 マッチング アクション 結果 アクション 照会パラメーターを XML に変換する アクション ( 設定はデフォルト ) AAA アクション (AAA ポリシー OAuth_RS を指定 ) 50

51 3. マルチプロトコル ゲートウェイを構成 (7/11) 2. 処理ポリシーの作成 (OAuthPolicy) ( 続き ) 5. レスポンス ルール (OAuthPolicy_rule_response) ここでは レスポンスに対する処理は何も実施しない サーバーからクライアント を選択 マッチング アクション 結果 アクション 51

52 3. マルチプロトコル ゲートウェイを構成 (8/11) 2. 処理ポリシーの作成 (OAuthPolicy) ( 続き ) 6. エラー ルール (OAuthPolicy_rule_error) デフォルト ( エラー ルールがない場合 ) は 処理エラーが SOAP/XML になります 処理ルール内のエラー時に エラー メッセージを JSON 形式へ変換する処理を実施 エラー を選択 マッチング アクション 結果 アクション XSLT スタイルシートを使用して変換する を選択 フェッチ アクション 変換 アクション 任意の XML ファイルを作成し IDG ローカルにアップロード dummy.xml の例 : <a>dummy</a> XSLT スタイルシートを作成し IDG ローカルにアップロード ( 次頁参照 ) 52

53 3. マルチプロトコル ゲートウェイを構成 (9/11) XSLT スタイルシート (error.xsl) エラー メッセージ ( サービス変数 :error-message) を JSON 形式で出力 <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" xmlns:dp=" 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> </xsl:stylesheet> 53

54 ( 参考 ) バックエンド エラーの処理 バックエンド サーバーからエラー コードを受信した場合の IDG での処理を設定可能 設定箇所 マルチプロトコル ゲートウェイの 拡張 タブの バックエンド エラーの処理 オン ( デフォルト ) レスポンス ルールで処理する オフ エラー ルールで処理し 処理が正常終了した場合 クライアントにエラー ルールで指定した応答コードを返す エラー ルール内で 変換 (Transform) アクションなどを使用してエラー コードの扱いを定義する必要がある 54

55 3. マルチプロトコル ゲートウェイを構成 (10/11) 3. HTTPS フロント サイド ハンドラーの作成 (OAuthFSH) リクエストを受け付けるポート番号を指定 ここでは 5070 を使用する デフォルトから GET メソッドを追加 SSL サーバー設定 ( 次頁参照 ) 55

56 3. マルチプロトコル ゲートウェイを構成 (11/11) 3. HTTPS フロント サイド ハンドラーの作成 (OAuthFSH) ( 続き ) 秘密鍵を指定 サーバー証明書を指定 56

57 ( 参考 ) サーバー証明書および秘密鍵の作成 IDG にて自己署名証明書を生成可能 管理 > その他 > 暗号ツール 57

58 実行結果例 (1/6) アクセス許可要求 (Basic 認証 ) Web ブラウザーにて以下の URL にアクセス d=oauthclient01&redirect_uri= %20/getCustomerInfo&state=MyTest リソース オーナーは許可サーバー上のユーザー名 / パスワードを入力して認証 認証後 リソース オーナーは許可するスコープを選択して Submit 許可コード取得 58

59 実行結果例 (2/6) アクセス許可要求 (Form 認証 ) Web ブラウザーにて以下の URL にアクセス ent_id=oauthclient01&redirect_uri= tinfo%20/getcustomerinfo&state=mytest リソース オーナーは許可サーバー上のユーザー名 / パスワードを入力して認証 認証後 リソース オーナーは許可するスコープを選択して Submit 許可コード取得 59

60 実行結果例 (3/6) アクセス トークン発行 curl にて以下のコマンドを実行 curl -k -d "grant_type=authorization_code&code=<authorization_code>&redirect_ur i= --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" } 60

61 実行結果例 (4/6) リソース アクセス curl にて以下のコマンドを実行 /getaccountinfo curl -k -H "Authorization:Bearer <Access_Token>" 応答電文 : { "name": "myaccount", "balance":1.00 } /getcustomerinfo curl -k -H "Authorization:Bearer <Access_Token>" 応答電文 : [ { "id":0, "name":"user01", "access_token":"aaent0f1dghdbgllbnqwmrgcj7ljvasb6cex82jlcosvw3qegyxi1w3340iktnoov 02aDzKZ6mLFkV3x88HpPz17_GKlqSvN3SFcLJd3YR94GKM8tpp8omrsyTyQQGLgwUOZy_sz3n44XgPv4VAOQ" } ] 61

62 実行結果例 (5/6) アクセス トークンの検査 curl にて以下のコマンドを実行 curl -k -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":" ", "not_after_text":" t11:08:51z", "not_before":" ", "not_before_text":" t10:08:51z", "resource_owner":"user01", "scope":"/getaccountinfo /getcustomerinfo" } NG ( トークンが期限切れの場合 ) { "valid":false } 62

63 実行結果例 (6/6) リフレッシュ トークンによるアクセス トークンの再発行 curl にて以下のコマンドを実行 curl -k -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- 1lQdBPjgBiESyKld0fSBO5iU2pAMrjGcuGdW1BXd6Fe3jm5SeVWgsOToS4O1Pur6Ukq0BisnOtMqCR83lw92gp1LMNrBFvs" } 63

64 ( 参考 ) バックエンド サーバーへの情報連携 HTTP ヘッダーにリソース オーナー クライアント ID スコープを付加することが可能 OAuth クライアント プロファイルの 拡張 タブ > HTTP ヘッダーの作成対象 にて設定 64

65 Tips: 許可コード アクセストークン発行後は 同じ許可コードは有効期限内であっても再利用不可 ただし 冗長構成の場合は注意が必要です 詳細は当資料 IDG の冗長構成について を参照してください リフレッシュトークン 有効なアクセストークンがある場合でもリフレッシュトークンで新規アクセストークンを発行可能 その際 古いアクセス トークンは失効されない そのため 有効なアクセストークンが複数できてしまうことが考えられます アクセストークン再発行に使用したリフレッシュトークンは 有効期限内であっても再利用不可 スコープ ただし 冗長構成の場合は注意が必要です 詳細は当資料 IDG の冗長構成について を参照してください IDG ではスコープを厳密にチェックするため 正確に定義する必要がある 例えば 許可スコープが /getaccountinfo の場合 /getaccountinfo/xxxx はスコープ検査により拒否される 許可スコープを /getaccountinfo* とすることで /getaccountinfo/xxxx へのアクセスも許可される 65

66 エラー応答例 (1/7) OAuth 処理エラー 例 : 不正な response_type が指定された場合 リクエスト curl -i -k " uthclient01&redirect_uri= stomerinfo&state=mytest" --user user01:password レスポンス OAuth クライアント プロファイルの 詳細エラー 設定にチェックがない場合 302 Processed Location: OAuth クライアント プロファイルの 詳細エラー 設定にチェックがある場合 302 Processed Location: ion=unsupported+response_type&state=mytest OAuth 処理エラーは OAuth 2.0 の仕様に準拠したエラー レスポンスとなります 詳細エラー (error_description) を応答させたい場合は設定が必要です ( 当資料 1. OAuth クライアントの登録 (3/5) を参照 ) 66

67 エラー応答例 (2/7) OAuth 処理エラー ( 続き ) 例 : 不正なスコープが指定された場合 リクエスト curl -i -k " uthclient01&redirect_uri= " --user user01:password レスポンス OAuth クライアント プロファイルの 詳細エラー 設定にチェックがない場合 302 Processed Location: OAuth クライアント プロファイルの 詳細エラー 設定にチェックがある場合 302 Processed Location: orted+scope&state=mytest OAuth 処理エラーは OAuth 2.0 の仕様に準拠したエラー レスポンスとなります 詳細エラー (error_description) を応答させたい場合は設定が必要です ( 当資料 1. OAuth クライアントの登録 (3/5) を参照 ) 67

68 エラー応答例 (3/7) OAuth 処理エラー ( 続き ) 例 : 不正な grant_type が指定された場合 リクエスト curl -i -k -d "grant_type=test&code=aak9yrspjg3trpyjkyr1rq93uh_ymljvt79g1zhozduwfhslkxw pnu7ffoxokavoqj10cwuftpum2rnpnuvh_is_qmv8ns9tlmwam2-vjdbwcafezs5l_9djfnmacuynfy&redirect_uri= --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) を参照 ) 68

69 エラー応答例 (4/7) OAuth 処理エラー ( 続き ) 例 : クライアント認証失敗 ( 不正なクライアント シークレット ) リクエスト curl -i -k -d "grant_type=authorization_code&code=aakmmjbta5zkfbhwn2nj1gmroz5fe07qfbszd Y6JYK8PuBcmwKvas9i0lDgkRilpqEtToKHUzNCDS674UOp6dLyV7XlmaU66EhCTfchPi4XyjZNFT_ztQn2Lfy6gnpIJg8&redirect_uri= --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) を参照 ) 69

70 エラー応答例 (5/7) OAuth 処理エラー ( 続き ) 例 : 許可コードの有効期限が切れている場合 リクエスト curl -i -k -d "grant_type=authorization_code&code=aajo1pynapeayndyftnzt3oiwk2eyoqj3rtjx NIn6CTcX3lTOGwnzagALZsE-Ahb046if1rTL8GIaYaZyyjS0OplciatSSAExWkQ5mqgVGHhp83Tgx-_WyWuXdAwMfXHSE&redirect_uri= - -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) を参照 ) 70

71 エラー応答例 (6/7) OAuth 処理エラー ( 続き ) 例 : アクセス トークンの有効期限が切れている場合 リクエスト curl -i -k -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. OAuth クライアントの登録 (3/5) を参照 ) 71

72 エラー応答例 (7/7) IDG 内部処理ルール エラー 例 : アクセス許可要求時に不正なクライアント ID が指定されている場合 リクエスト curl -i -k " uthclient99&redirect_uri= stomerinfo&state=mytest" --user user01:password レスポンス 400 Error {"errormsg" : "Failed to verify OAuth information."} 例 : 不正なユーザーからのアクセス許可要求 リクエスト curl -i -k " Client01&redirect_uri= merinfo&state=mytest" --user user99:password レスポンス 401 Unauthorized {"errormsg" : "Rejected by policy."} エラー電文はエラー ルールにて定義したものです ( 当資料 3. マルチプロトコル ゲートウェイを構成 (8-9/11) を参照 ) 72

73 OAuth プロセスのカスタマイズ 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) 74

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

76 OAuth プロセスのカスタマイズ (3/3) IBM DataPower Gateway (IDG) リソース オーナー OAuth クライアント 許可サーバー エンドポイント & リソース サーバー適用ポイント リソース サーバー アクセス許可要求 認証 Basic Authentication 許可フォーム 2. 許可フォームのカスタマイズ Scope Accept 11. preapproved_check 処理 4. authorization_form 処理 1. カスタム スコープ検査 許可コード アクセス トークン発行要求 3. リソース所有者カスタム処理 アクセス トークン リソース要求 Publish code 12. miscinfo_request 処理処理 5. authorization_request 処理 Validate code & Publish token 6. access_request 処理 Check token 10. check_revocation_request 処理 アクセス トークン検査要求 8. resource_request 処理 Validate token アクセス トークン失効要求 success Revoke token 7. validate_request 処理 9. revoke_request 処理 76

77 カスタム スコープ検査 (1/5) 設定方法 OAuth クライアント プロファイルにて設定 1. カスタム スコープ検査 メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル で カスタマイズしたいプロファイルを選択表示し メイン タブの カスタマイズ スコープ検査 にチェックを入れる スコープ カスタマイズ処理 にて作成した XSLT ( または GatewayScript) を指定する カスタマイズ サンプル 許可要求に含まれるスコープが事前定義した許可スコープ一覧に合致しているかを検査し 合致しているスコープのみを許可フォームに表示する 実装方法 許可スコープ一覧の定義ファイル (OAuth_Scopes.xml) の作成 スコープ カスタマイズ処理の XSLT ファイル (dp-custom-validate-scope.xsl) の作成 77

78 カスタム スコープ検査 (2/5) 許可スコープ一覧の定義ファイル (OAuth_Scopes.xml) 1. カスタム スコープ検査 <?xml version="1.0" encoding="utf-8"?> <scopes> <scope>/getaccountinfo</scope> <scope>/getcustomerinfo</scope> </scopes> 78

79 カスタム スコープ検査 (3/5) スコープ カスタマイズ処理の XSLT ファイル (dp-custom-validatescope.xsl) <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" xmlns:str=" xmlns:regexp=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig str regexp"> 1. カスタム スコープ検査 許可スコープ定義ファイルの読み込み <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 認証用 ) 79

80 カスタム スコープ検査 (4/5) スコープ カスタマイズ処理の XSLT ファイル (dp-custom-validatescope.xsl) ( 続き ) <xsl:variable name="splited-scopes"> <xsl:copy-of select="str:tokenize($translated-scope-from-url, ' ')"/> </xsl:variable> 1. カスタム スコープ検査 <xsl:variable name="resource"> <xsl:for-each select="$splited-scopes/token"> <xsl:if test="text() = $props//scope"> <xsl:value-of select="text()"/> <xsl:text> </xsl:text> </xsl:if> </xsl:for-each> </xsl:variable> スコープを半角スペース区切りで分割 分割したスコープから 許可スコープ定義ファイルと一致するもののみを抽出 <result> <xsl:choose> <xsl:when test="$resource!= ''"> <dp:set-request-header name="'x-account-modified'" value="'yes'"/> <scope><xsl:value-of select="normalize-space($resource)"/></scope> </xsl:when> <xsl:otherwise> <error>requested scope is not allowed</error> </xsl:otherwise> </xsl:choose> </result> </xsl:template> </xsl:stylesheet> 80

81 カスタム スコープ検査 (5/5) 確認結果 リクエスト URL 1. カスタム スコープ検査 AuthClient01&redirect_uri= /getcustomerinfo%20/getprofile&state=mytest 許可フォーム 許可されていないスコープ 許可されるスコープのみ表示される 81

82 許可フォームのカスタマイズ (1/3) 設定方法 OAuth クライアント プロファイルにて設定 2. 許可フォームのカスタマイズ メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル で カスタマイズしたいプロファイルを選択表示し メイン タブの 許可フォーム にて カスタマイズした XSLT ( または GatewayScript) を指定する カスタマイズ サンプル スコープの文字列を日本語に変換して許可フォームに表示する 実装方法 カスタマイズした XSLT ファイル (OAuth-Generate-HTML_custom.xsl) の作成 ここでは デフォルトで提供される store:///oauth-generate-html.xsl をカスタマイズ 82

83 許可フォームのカスタマイズ (2/3) OAuth-Generate-HTML_custom.xsl 2. 許可フォームのカスタマイズ <body> ~~~ 途中省略 ~~~ <xsl:for-each select="$scopes"> <xsl:choose> <xsl:when test="text() = '/getaccountinfo'"> <br/><input type="checkbox" checked="yes" name="selectedscope" value="{text()}"/><xsl:value-of select="' アカウント照会 '"/> </xsl:when> <xsl:when test="text() = '/getcustomerinfo'"> <br/><input type="checkbox" checked="yes" name="selectedscope" value="{text()}"/><xsl:value-of select="' 顧客照会 '"/> </xsl:when> <xsl:otherwise> <br/><input type="checkbox" checked="yes" name="selectedscope" value="{text()}"/><xsl:value-of select="text()"/> </xsl:otherwise> </xsl:choose> </xsl:for-each> <br/><br/> </xsl:if> ~~~ 途中省略 ~~~ </body> 83

84 許可フォームのカスタマイズ (3/3) 確認結果 リクエスト URL 2. 許可フォームのカスタマイズ AuthClient01&redirect_uri= /getcustomerinfo&state=mytest 許可フォーム 84

85 リソース所有者カスタム処理 (1/6) 設定方法 OAuth クライアント プロファイルにて設定 3. リソース所有者カスタム処理 メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル で カスタマイズしたいプロファイルを選択表示し 拡張 タブの リソース所有者カスタム処理 にチェックを入れる リソース所有者処理 で作成した XSLT ( または GatewayScript) を指定する カスタマイズ サンプル 許可コード発行時にリソース オーナーの情報を暗号化する 実装方法 カスタマイズした XSLT ファイル (dp-encrypted-resource-owner.xsl) の作成 85

86 リソース所有者カスタム処理 (2/6) dp-encrypted-resource-owner.xsl 3. リソース所有者カスタム処理 <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> <xsl:template match="/"> <result> <!-- encrypt the credential, so it will not be shown on the html page --> <xsl:variable name="oauth-identity" <!-- determine the actual resource owner identity --> <xsl:variable name="name"> <xsl:choose> <xsl:when test="string(/input//mapped-credentials//username)!= ''"> <xsl:value-of select="/input//mapped-credentials//username"/> </xsl:when> <xsl:when test="string(/input//mapped-credentials//dn)!= ''"> <xsl:value-of select="/input//mapped-credentials//dn"/> </xsl:when> <xsl:when ''"> <xsl:value-of </xsl:when> <xsl:when test="string(/input/credentials//usernname)!= ''"> <xsl:value-of select="/input/credentials//usernname"/> </xsl:when> リソース オーナー情報の指定 86

87 リソース所有者カスタム処理 (3/6) dp-encrypted-resource-owner.xsl ( 続き ) 3. リソース所有者カスタム処理 <xsl:when test="string(/input/credentials//usernname)!= ''"> <xsl:value-of select="/input/credentials//usernname"/> </xsl:when> <xsl:when test="string(/input/identity//entry[@type='oauth']//resource_owner)!= ''"> <xsl:value-of select="/input/identity//entry[@type='oauth']//resource_owner"/> </xsl:when> <xsl:when test="string(/input/identity//entry[@type='oauth']//username)!= ''"> <xsl:value-of select="/input/identity//entry[@type='oauth']//username"/> </xsl:when> <xsl:otherwise> <xsl:value-of select="/input/identity//usernname"/> </xsl:otherwise> </xsl:choose> </xsl:variable> <xsl:choose> <xsl:when test="$oauth-identity//oauth-id/@type = 'authorization_request'"> <!-- this only occurs during initial request with either authorization code or implicit grant type --> <resource-owner-name><xsl:value-of select="dp:encrypt-string(' 'hex: ', $name)"/></resource-owner-name> </xsl:when> <xsl:otherwise> <resource-owner-name><xsl:value-of select="$name"/></resource-owner-name> </xsl:otherwise> </xsl:choose> </result> </xsl:template> </xsl:stylesheet> リソース オーナー情報の指定 リソース オーナー情報を暗号化してオーバーライド 87

88 リソース所有者カスタム処理 (4/6) リソース オーナー暗号化結果 3. リソース所有者カスタム処理 88

89 リソース所有者カスタム処理 (5/6) リソース サーバーに対してリソース オーナー情報を連携する場合などは 以下のコードで復号化可能 例 : 追加 OAuth 処理のカスタマイズにより復号化 <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> 3. リソース所有者カスタム処理 resource_request 処理のカスタマイズにより復号化し ヘッダーに追加 <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'resource_request'"> <xsl:variable name="result" select="/input/container/identity/entry[@type='oauth']/oauth-verified[@state='ok']/result" /> <xsl:variable name="resowner" select="$result/verified-access-token/resource_owner" /> <xsl:variable name="decrypted" select="dp:decrypt-data(' 'hex: ',$resowner)"/> <dp:set-request-header name="'dp-resourceowner'" value="$decryptedowner"/> </xsl:when> <xsl:otherwise /> </xsl:choose> </xsl:template> </xsl:stylesheet> 89

90 リソース所有者カスタム処理 (6/6) リソース オーナー復号化結果 3. リソース所有者カスタム処理 90

91 追加 OAuth 処理 設定方法 OAuth クライアント プロファイルにて設定 メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル で カスタマイズしたいプロファイルを選択表示し 拡張 タブの 追加 OAuth 処理 にて作成した XSLT ファイル ( または GatewayScript) を指定する 91

92 追加 OAuth 処理 authorization_request (1/3) authorization_request 処理のカスタマイズ サンプル 許可コード応答時に追加情報 ( ここでは リソース オーナーのユーザー名 ) を付加する 実装方法 カスタマイズした XSLT ファイル (add-process_az-request.xsl) の作成 5. authorization_request 処理 92

93 追加 OAuth 処理 authorization_request (2/3) add-process_az-request.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> authorization_request 処理の操作 <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'authorization_request'"> <xsl:variable name="clientid" select="/input/container/identity/entry[@type = 'oauth']//oauthsupportedclient/client-id"/> <xsl:choose> <xsl:when test="$clientid = 'OAuthClient01'"> <xsl:if test="/input/container/identity/entry//username[1]"> <result> <username><xsl:value-of select="/input/container/identity/entry//username[1]"/></username> </result> </xsl:if> </xsl:when> 5. authorization_request 処理 クライアント ID が OAuthClient01 の場合 <result> に <username> を付加 <xsl:when test="/input/container/identity/entry[@type = 'oauth']//oauthsupportedclient/client-id = 'OtherClient'"> <!-- this set information in a context variable for future processing --> <dp:set-variable name="'var://context/myoauth/logging'" value="concat('code:', $clientid, ':', /input/result/code)"/> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:template> </xsl:stylesheet> 93

94 追加 OAuth 処理 authorization_request (3/3) 確認結果 ( ブラウザー ) アクセス許可要求 ( user01 で Basic 認証 ) 5. authorization_request 処理 thclient01&redirect_uri= tomerinfo&state=mytest 許可コード発行結果 許可コード応答時にユーザー名が含まれる 94

95 追加 OAuth 処理 access_request (1/3) access_request 処理のカスタマイズ サンプル アクセス トークン要求に対する応答メッセージに追加情報 ( ここでは OAuth クライアントのクライアント ID と任意の ID) を付加する 実装方法 6. access_request 処理 カスタマイズした XSLT ファイル (add-process_access-request.xsl) の作成 add-process_access-request.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'access_request'"> <xsl:variable name="clientid" select="/input/container/identity/entry[@type = 'oauth']//oauthsupportedclient/client-id"/> ( 次頁へ続く ) access_request 処理の操作 95

96 追加 OAuth 処理 access_request (2/3) add-process_access-request.xsl ( 続き ) <xsl:choose> <xsl:when test="$clientid = 'OAuthClient01'"> <xsl:if test="/input/container/identity/entry//username[1]"> <result> 6. access_request 処理 クライアント ID が OAuthClient01 の場合 <result> に <username> と <id_token> を付加 <username><xsl:value-of select="/input/container/identity/entry//username[1]"/></username> <!-- this allow you to provide your own id_token support --> <id_token><xsl:value-of select="' '"/></id_token> </result> </xsl:if> </xsl:when> <xsl:when test="/input/container/identity/entry[@type = 'oauth']//oauthsupportedclient/client-id = 'OtherClient'"> <!-- this set information in a context variable for future processing --> <dp:set-variable name="'var://context/myoauth/logging'" value="concat('access_token:', $clientid, ':', /input/result/access_token)"/> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:template> </xsl:stylesheet> 96

97 追加 OAuth 処理 access_request (3/3) 確認結果 (curl) 6. access_request 処理 $ curl -i -k -d "grant_type=authorization_code&code=aajjqsagj_hjqguv9cjcpzoknqb25yn09zsjhnikpviwjdfkckewv tashg2sv2elvlmmw36_akvxxxrqcfwy2jnymzr5kuqt4vhjgnz0mm2ube1xvjr7zoinxh0tm2x4psy&redirect_u ri= --user OAuthClient01:passw0rd % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent アクセス トークン発行要求 Left Speed :--:-- --:--:-- --:--: HTTP/ OK X-Backside-Transport: FAIL FAIL Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json Cache-Control: private, no-store, no-cache, must-revalidate アクセス トークン発行時の応答にク Pragma: no-cache ライアントIDと任意のIDが付加される { "token_type":"bearer", "access_token":"aaent0f1dghdbgllbnqwmztlyzejquh5rafkofv7ebbztoxqqenmimxhu8h9r8ws51vkchbd3 1qCzArFJ9AzGON2DoLRUyME-kM8KNc1eu4hAwYSXzbpvpR UE1AyXCDbpUGUe1J0NK-zuSFIowEw", "expires_in":3600, "scope":"/getaccountinfo /getcustomerinfo", "refresh_token":"aahd7ghqrju51njhxjhm- _5hdPRjOPj6qzEIvvunS80hms3wZBJxuEWRug6G7QiOPps38R5N4oRmFILodKmePABOCxWdSjAO-G3Lih- WYeIwntmFAeaaiEx-3Z1lhY30CvY", "username":"oauthclient01", "id_token":" " } 97

98 追加 OAuth 処理 validate_request (1/3) validate_request 処理のカスタマイズ サンプル アクセス トークン検査要求に対する応答メッセージに追加情報 ( ここでは IDG が生成するトランザクション ID) を付加する 実装方法 7. validate_request 処理 カスタマイズした XSLT ファイル (add-process_validate-request.xsl) の作成 98

99 追加 OAuth 処理 validate_request (2/3) add-process_validate-request.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> 7. validate_request 処理 <xsl:template match="/"> validate_request 処理の操作 <xsl:choose> <xsl:when test="/input/operation = 'validate_request'"> <!-- <result> <addinfo>ddd</addinfo>... <times type='json:number'>text</times> </result> レスポンスにトランザクションIDを付加 --> <result> <uuid><xsl:value-of select="dp:generate-uuid()"/></uuid> </result> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:template> </xsl:stylesheet> 99

100 追加 OAuth 処理 validate_request (3/3) 確認結果 (curl) 7. validate_request 処理 $ curl -i -k -d "grant_type=urn:ibm:datapower:validate&access_token=aaent0f1dghdbgllbnqwmtbksybiacsbktat6_rr1by53hdf6foccdhze8itsjrzerodpeugb5x3enpituk5qo2zeuvhhx0hyfz6mwip7od2fbm_jwbxl0qrmussq9eyhkrrd4wg9kh omm9p1ozq" --user OAuthClient01:passw0rd % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent アクセス トークン検査要求 Left Speed :--:-- --:--:-- --:--: HTTP/ OK X-Backside-Transport: FAIL FAIL Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json 応答メッセージにIDGが生成するト Cache-Control: private, no-store, no-cache, must-revalidate ランザクションIDが付加される Pragma: no-cache { "valid":true, "token_type":"bearer", "client_id":"oauthclient01", "not_after":" ", "not_after_text":" t08:22:19z", "not_before":" ", "not_before_text":" t07:22:19z", "resource_owner":"user01", "scope":"/getaccountinfo /getcustomerinfo", "uuid":"39df2d82- f1f2-4d1d-887f-b25ceb27abbb" } 100

101 追加 OAuth 処理 resource_request (1/3) resource_request 処理のカスタマイズ サンプル 保護リソースへのアクセス時に以下の処理を行う IDG コンテキスト変数に情報 ( ここでは OAuth クライアント ID とリソース オーナー名 ) を格納 リクエスト ヘッダーに情報 ( ここでは クライアント ID) を付加 実装方法 8. resource_request 処理 カスタマイズした XSLT ファイル (add-process_resource-request.xsl) の作成 101

102 追加 OAuth 処理 resource_request (2/3) add-process_resource-request.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'resource_request'"> <xsl:variable name="clientid" select="/input/container/identity/entry[@type = 'oauth']//oauthsupportedclient/client-id"/> <xsl:if test="$clientid = 'OAuthClient01'"> <dp:set-variable name="'var://context/myoauth/logging'" value="concat('resource:', $clientid, ':', /input/container/identity/entry//username[1])"/> <dp:set-request-header name="'forbackend'" value="$clientid"/> </xsl:if> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:template> </xsl:stylesheet> resource_request 処理の操作 8. resource_request 処理 クライアント ID が OAuthClient01 の場合 コンテキスト変数にクライアント ID とリソース オーナー名を格納し リクエスト ヘッダーにクライアント ID を付加 102

103 追加 OAuth 処理 resource_request (3/3) 確認結果 (curl) リソース要求 curl -i -k -H "Authorization:Bearer <Access_Token>" 8. resource_request 処理 カスタマイズ処理後のリクエスト ヘッダーとコンテキスト変数 リクエスト ヘッダー コンテキスト変数 コンテキスト変数にクライアント ID とリソース オーナー名が付加される ForBackEnd ヘッダーにクライアント ID が付加される 103

104 追加 OAuth 処理 preapproved_check (1/3) preapproved_check 処理のカスタマイズ サンプル リソース オーナーに対する許可要求を事前承認し 許可フォームをバイパスする 実装方法 11. preapproved_check 処理 カスタマイズした XSLT ファイル (add-process_preapproved-check.xsl) の作成 104

105 追加 OAuth 処理 preapproved_check (2/3) add-process_preapproved-check.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> 11. preapproved_check 処理 preapproved_checkt 処理の操作 <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'preapproved_check'"> <!-- <result> <approved>yes no</approved> return an empty node will force the authorization form to be displayed </result> --> クレデンシャルが USER01 の場合 <xsl:choose> <approved> の値をyesに設定 <xsl:when test="/input/container/credentials/entry = 'USER01'"> <result><approved>yes</approved></result> </xsl:when> <xsl:when test="/input/container/credentials/entry = 'notauthenticated'"> <result><approved>no</approved></result> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:template> </xsl:stylesheet> 105

106 追加 OAuth 処理 preapproved_check (3/3) 確認結果 (curl) 11. preapproved_check 処理 $ curl -i -k " &scope=/getaccountinfo%20/getcustomerinfo&state=mytest" --user user01:password -v -o test.html < 途中省略 > アクセス許可要求 (user01 で Basic 認証 ) > GET /oauth/authz?response_type=code&client_id=oauthclient01&redirect_uri= CustomerInfo&state=MyTest HTTP/1.1 > Authorization: Basic dxnlcjaxonbhc3n3b3jk > User-Agent: curl/ (x86_64-pc-win32) libcurl/ OpenSSL/0.9.8r zlib/1.2.5 > Host: :5070 > Accept: */* > :--:-- --:--:-- --:--:-- 0< HTTP/ Processed < X-Backside-Transport: FAIL FAIL < Connection: Keep-Alive < Transfer-Encoding: chunked < Location: F4z7L5Z0ms6RZeJ3iPv2OsmcjEnE8CYm-wVxorHZ7KymGDO_-QJ7SzF32L1K27Ps-Cj6CEd5D1tNdFw8&state=MyTest < Content-Type: text/xml < Cache-Control: private, no-cache, no-store, must-revalidate < { [data not shown] :--:-- --:--:-- --:--: * Connection #0 to host left intact * Closing connection #0 * SSLv3, TLS alert, Client hello (1): } [data not shown] 許可フォームによる承認をバイパスして許可コードが発行される 106

107 追加 OAuth 処理 miscinfo_request (1/3) miscinfo_request 処理のカスタマイズ サンプル アクセス トークンに含まれる情報を追加する 12. miscinfo_request 処理 実装方法 カスタマイズした XSLT ファイル (add-process_miscinfo-request.xsl) の作成 Tips: 情報は <miscinfo> タグで追加する必要がある miscinfo_requestは以下の各オペレーションで処理される dp-state az-code access-tokenの順で処理される 情報は自動的に後続処理に渡される 後続処理で情報をオーバーライド可能 operation type dp-state az-code access-token カスタマイズ内容許可フォームに追加情報を含めることが可能 許可コードに追加情報含めることが可能 アクセス トークンに追加情報を含めることが可能 107

108 追加 OAuth 処理 miscinfo_request (2/3) add-process_miscinfo-request.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'miscinfo_request'"> <xsl:choose> <xsl:when test="/input/operation/@type = 'dp-state'"> <xsl:if test="/input/container/identity/entry[@type='oauth']//oauthsupportedclient/client-id = 'AddClientId'"> <result><miscinfo><xsl:value-of select="/input/container/credentials/entry//sso-sessionid"/></miscinfo></result> </xsl:if> </xsl:when> <xsl:when test="/input/operation/@type = 'az-code'"> <xsl:if test="/input/container/identity/entry[@type='oauth']//oauthsupportedclient/client-id = 'AddClientId'"> <result><miscinfo><xsl:value-of select="/input/container/identity/entry//sso-sessionid"/></miscinfo></result> </xsl:if> </xsl:when> <xsl:when test="/input/operation/@type = 'access-token'"> <xsl:if test="/input/container/identity/entry[@type='oauth']//oauthsupportedclient/client-id = 'OAuthClient01'"> <result><miscinfo> </miscinfo></result> </xsl:if> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:when> <xsl:otherwise/> </xsl:choose> </xsl:template> </xsl:stylesheet> miscinfo_request 処理の操作 12. miscinfo_request 処理 operation type が access-token の処理時に <miscinfo> の値に追加の文字列を設定 108

109 追加 OAuth 処理 miscinfo_request (3/3) 確認結果 (curl) $ curl -i -k -d "grant_type=urn:ibm:datapower:validate&access_token=aaent0f1dghdbgllbnqwmxzabbs7uf_d1frqp foso07ob16pikeezytqy- a8gqq95077kluhiezhwl1hxki7gqk48qp8xjkryyl4yeto14ldmargndzv1vcl3lvreiu W-pRPoEqbdx30EY_- QGp9a8a5Py5gQdXZeYr-A4hQw" --user OAuthClient01:passw0rd % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent アクセス トークン検査要求 Left Speed :--:-- --:--:-- --:--: HTTP/ OK X-Backside-Transport: FAIL FAIL Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json Cache-Control: private, no-store, no-cache, must-revalidate Pragma: no-cache { "valid":true, "token_type":"bearer", "client_id":"oauthclient01", "not_after":" ", "not_after_text":" t09:02:15z", "not_before":" ", "not_before_text":" t08:02:15z", "resource_owner":"user01", "scope":"/getaccountinfo /getcustomerinfo", "miscinfo": " } アクセス トークン検査要求で miscinfo が追加されていることを確認可能 12. miscinfo_request 処理 109

110 トークン失効管理 110

111 IDG におけるトークン失効方法 (1/2) 事前に IDG にてトークン失効の有効化が必要 設定方法は トークン失効管理方法により異なる ( 後述 ) OAuth クライアントまたはリソース オーナーから失効リクエスト送信が可能 OAuth クライアントから失効する場合 特定のトークンの失効が可能 OAuth クライアントのクレデンシャルが必要 curl による失効リクエスト例 アクセス トークンの失効要求 curl -k -d "grant_type=urn%3aibm%3adatapower%3aclient%3arevoke&access_token=<access_token>" --user OAuthClient01:passw0rd リフレッシュ トークンの失効要求 curl -k -d "grant_type=urn%3aibm%3adatapower%3aclient%3arevoke&refresh_token=<refresh_token>" --user OAuthClient01:passw0rd アクセス トークンおよびリフレッシュ トークンの失効要求 応答電文例 curl -k -d "grant_type=urn%3aibm%3adatapower%3aclient%3arevoke&access_token=<access_token>&refresh_t oken=<refresh_token>" --user OAuthClient01:passw0rd OK:HTTP 200 { "status":"success" } NG:HTTP 200 { "status":"failure" } 111

112 IDG におけるトークン失効方法 (2/2) OAuth クライアントまたはリソース オーナーから失効リクエスト送信が可能 ( 続き ) リソース オーナーから失効する場合 特定の OAuth クライアントの失効が可能 リソース オーナーのクレデンシャルが必要 curl による失効リクエスト例 OAuth クライアントの失効要求 応答電文例 curl -k -d "grant_type=urn%3aibm%3adatapower%3aowner%3arevoke&client_id=<oauth_client_id>" --user user01:password OK:HTTP 200 { "status":"success" } NG:HTTP 200 { "status":"failure" } 112

113 IDG におけるトークン失効管理 IDG ではトークン失効管理として以下の 2 つの方法が考えられる IDG 内部キャッシュを利用 IDG がトークン失効要求を受信した際に 内部キャッシュにてトークン失効情報を管理する IDG はリソース アクセス時に内部キャッシュを参照してトークン失効検査を実施する 外部リポジトリーを利用 推奨 IDG がトークン失効要求を受信した際に 外部リポジトリーへ失効情報を連携し 外部リポジトリーにてトークン失効情報を管理する IDG はリソース アクセス時に外部リポジトリーを参照してトークン失効検査を実施する 113

114 IDG 内部キャッシュの利用 (1/3) IDG 設定方法 OAuth クライアント プロファイルにて設定 メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル で カスタマイズしたいプロファイルを選択表示し 拡張 タブの キャッシング にて トークン キャッシュ を選択 114

115 IDG 内部キャッシュの利用 (2/3) IDG は定期的に内部キャッシュをチェックし 期限切れエントリーを削除する 更新間隔は変更不可 OAuth キャッシュは メニューより 状況 > 暗号 > OAuth キャッシュ にて確認可能 タイプ備考更新間隔 許可フォーム状態許可コードアクセス トークン * リフレッシュ トークン 許可フォーム状態 (dpstate) のキャッシュ リソース オーナーから IDG へ許可フォーム返答後に表示される 許可コード (azcode) のキャッシュ アクセス トークン発行後に表示される アクセス トークン (access) のキャッシュ アクセス トークンを失効させた場合に表示される リフレッシュ トークン (refresh) のキャッシュ リフレッシュ トークンを使用した場合 または失効させた場合に表示される 15 分 30 分 * OAuth クライアント プロファイルの 拡張 タブ > キャッシング 設定が トークン キャッシュ の場合のみ表示されます 115

116 IDG 内部キャッシュ利用時の考慮点 OAuth キャッシュは IDG システム ( 筐体 ) 停止により消滅する ドメイン再起動では消滅しません IDG が起動した際に 有効期限内のトークンでかつ失効されているトークンは再度失効リクエストを送信する必要があります 複数台の IDG で冗長構成とする場合 各 IDG に失効リクエストを送信する必要がある そのため 以下の検討が必要 失効リクエストは誰がどのように送信するのか 例えば IDG 管理者が外部アプリケーションから IDG に対して失効リクエストを送信するなど IDG の監視方法 例えば IDG に対して定期的にヘルスチェックするなど 116

117 外部リポジトリーの利用 (1/11) 前提 トークンを管理するための外部リポジトリーが必要 ここでは サンプルとして Node.js を使用し IDG から Node.js に対して HTTP で失効要求および失効チェックを行います Node.js のサンプル コードは下記リンク先 developerworks より入手可能です &filename=code_sample.zip&method=http&locale= サンプル コードの使用方法は 上記リンク先で提供される README ファイルを参照してください 事前に Node.js および node-cache モジュールをインストールする必要があります node-cache モジュールは以下のコマンドでインストール可能です npm install node-cache 117

118 外部リポジトリーの利用 (2/11) IDG 設定方法 OAuth クライアント プロファイルにて設定 メニューより オブジェクト > 暗号構成 > OAuth クライアント プロファイル で カスタマイズしたいプロファイルを選択表示し 拡張 タブの キャッシング にて カスタム を選択 追加 OAuth 処理 にてカスタマイズした XSLT ファイル ( または GatewayScript) を選択 6. access_request 処理 9. check_revocation_request 処理 10. revoke_request 処理 XSLT ファイル ( または GatewayScript) にて revoke_request / check_revocation_request / access_request 処理の操作をカスタマイズし 外部リポジトリーに問い合わせる 118

119 外部リポジトリーの利用 (3/11) revoke_addprocess.xsl <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet xmlns:xsl=" version="1.0" xmlns:dp=" xmlns:dpconfig=" xmlns:dpfunc=" extension-element-prefixes="dp dpfunc" exclude-result-prefixes="dp dpfunc dpconfig"> 外部リポジトリーの宛先 URL を指定 <xsl:variable name="cache-server-url" select="' <xsl:template match="/"> <xsl:choose> <xsl:when test="/input/operation = 'revoke_request'"> <!-- call to store the information --> <result> <xsl:choose> <xsl:when test="/input/resource_owner and /input/client_id"> <xsl:variable name="url-query"> <xsl:value-of select="$cache-server-url"/> <xsl:text>/owner-revoke?client_id=</xsl:text> <xsl:value-of select="/input/client_id"/> <xsl:text>&resource_owner=</xsl:text> <xsl:value-of select="/input/resource_owner"/> <xsl:text>&access_token_ttl=</xsl:text> <xsl:value-of select="/input/entry/oauthsupportedclient/access-token-lifetime"/> <xsl:if test="/input/entry/oauthsupportedclient/refresh-token-lifetime"> <xsl:text>&refresh_token_ttl=</xsl:text> <xsl:value-of select="/input/entry/oauthsupportedclient/refresh-token-lifetime"/> </xsl:if> </xsl:variable> <xsl:message dp:priority="info"><xsl:value-of select="$url-query"/></xsl:message> ( 次頁へ続く ) revoke_request 処理のカスタマイズ 外部リポジトリーに対するリクエスト URL の形成 119

120 外部リポジトリーの利用 (4/11) revoke_addprocess.xsl ( 続き ) ( 次頁へ続く ) <!-- in reality, we should check for the return code to make sure the cache is actually stored --> <xsl:variable name="message-response"> <dp:url-open target="{$url-query}" response="responsecode-ignore"> </dp:url-open> </xsl:variable> <status>success</status> </xsl:when> 外部リポジトリーへアクセス <xsl:when test="/input/access_token or /input/refresh_token"> <xsl:variable name="url-query"> <xsl:value-of select="$cache-server-url"/> <xsl:text>/client-revoke?</xsl:text> <xsl:if test="/input/access_token"> <xsl:text>access_token=</xsl:text> <xsl:value-of select="/input/access_token"/> <xsl:text>&access_token_ttl=</xsl:text> <xsl:value-of select="/input/oauthsupportedclient/access-token-lifetime"/> </xsl:if> <xsl:if test="/input/refresh_token"> <xsl:if test="/input/access_token"> <xsl:text>&</xsl:text> </xsl:if> <xsl:text>refresh_token=</xsl:text> <xsl:value-of select="/input/refresh_token"/> <xsl:text>&refresh_token_ttl=</xsl:text> <xsl:value-of select="/input/oauthsupportedclient/refresh-token-lifetime"/> </xsl:if> </xsl:variable> <xsl:message dp:priority="info"><xsl:value-of select="$url-query"/></xsl:message> 120

121 外部リポジトリーの利用 (5/11) revoke_addprocess.xsl ( 続き ) <!-- in reality, we should check for the return code to make sure the cache is actually stored --> <xsl:variable name="message-response"> <dp:url-open target="{$url-query}" response="responsecode-ignore"> </dp:url-open> </xsl:variable> <status>success</status> </xsl:when> <xsl:otherwise> <status>failure</status> <error>invalid_request</error> <error_description>not enough info for operation</error_description> </xsl:otherwise> </xsl:choose> </result> </xsl:when> <!-- End of revoke-request --> access_request 処理のカスタマイズ <xsl:when test="/input/operation = 'access_request'"> <xsl:choose> <xsl:when test="/input/container/identity/entry[@type='oauth']/oauth-id[@type='access_request']/grant_type = 'refresh_token'"> <!-- record the refresh token as revoked --> <xsl:variable name="url-query"> <xsl:value-of select="$cache-server-url"/> <xsl:text>/client-revoke?</xsl:text> <xsl:text>refresh_token=</xsl:text> <xsl:value-of select="/input/container/identity/entry[@type='oauth']/oauthid[@type='access_request']/refresh_token"/> <xsl:text>&refresh_token_ttl=</xsl:text> <xsl:value-of select="/input/container//oauthsupportedclient/refresh-token-lifetime"/> </xsl:variable> ( 次頁へ続く ) 121

122 外部リポジトリーの利用 (6/11) revoke_addprocess.xsl ( 続き ) <xsl:message dp:priority="info"><xsl:value-of select="$url-query"/></xsl:message> <!-- in reality, we should check for the return code to make sure the cache is actually stored --> <xsl:variable name="message-response"> <dp:url-open target="{$url-query}" response="responsecode-ignore"> </dp:url-open> </xsl:variable> </xsl:when> <xsl:when test="/input/container/identity/entry[@type='oauth']/oauth-id[@type='access_request']/grant_type = 'authorization_code'"> <!-- record the refresh token as revoked --> <xsl:variable name="url-query"> <xsl:value-of select="$cache-server-url"/> <xsl:text>/client-revoke?</xsl:text> <xsl:text>az_code=</xsl:text> <xsl:value-of select="/input/container/identity/entry[@type='oauth']/oauth-id[@type='access_request']/code"/> <xsl:text>&az_code_ttl=</xsl:text> <xsl:value-of select="/input/container//oauthsupportedclient/au-code-lifetime"/> </xsl:variable> <xsl:message dp:priority="info"><xsl:value-of select="$url-query"/></xsl:message> <!-- in reality, we should check for the return code to make sure the cache is actually stored --> <xsl:variable name="message-response"> <dp:url-open target="{$url-query}" response="responsecode-ignore"> </dp:url-open> </xsl:variable> </xsl:when> </xsl:choose> </xsl:when> <!-- End of access_request --> ( 次頁へ続く ) 122

123 外部リポジトリーの利用 (7/11) revoke_addprocess.xsl ( 続き ) <xsl:when test="/input/operation = 'check_revocation_request'"> <xsl:variable name="url-query"> <xsl:value-of select="$cache-server-url"/> <xsl:text>/check-revoke?client_id=</xsl:text> <xsl:value-of select="/input/verified-token/client_id"/> <xsl:text>&resource_owner=</xsl:text> <xsl:value-of select="/input/verified-token/resource_owner"/> <xsl:text>&token_type=</xsl:text> <xsl:value-of select="/input/operation/@token-type"/> <xsl:text>&token=</xsl:text> <xsl:value-of select="/input/token"/> <!-- in theory, user has the created date of the token, and they can write more complex logic to only revoke those access created before resource owner revoke the client --> </xsl:variable> <xsl:message dp:priority="info"><xsl:value-of select="$url-query"/></xsl:message> <!-- in reality, we should check for the return code to make sure the cache is actually stored --> <xsl:variable name="message-response"> <dp:url-open target="{$url-query}" response="responsecode-ignore"> </dp:url-open> </xsl:variable> <xsl:if test="$message-response/url-open/headers/header[@name='x-dp-revoked'] = 'true'"> <result><revoked>revoked by checking external storage</revoked></result> </xsl:if> </xsl:when> <!-- End of check_revocation_request --> <xsl:when test="/input/operation = 'preapproved_check'"> <result><approved>yes</approved></result> </xsl:when> </xsl:choose> </xsl:template> </xsl:stylesheet> check_revocation_request 処理のカスタマイズ 123

124 外部リポジトリーの利用 (8/11) 確認結果 curl アクセス トークン発行 $ curl -i -k -d "grant_type=authorization_code&code=aaizi878lono9aec1x- qpffwpmsojdsc_ud4- gwizls2h4mxwzaptchy_weze48v80jjlgb_jqmazdp2hv6a1iga8qymanttf1cxpr 6Abag2_AwBNGK6sSDzci9GgCzqb2A&redirect_uri= -- user OAuthClient01:passw0rd HTTP/ OK X-Backside-Transport: FAIL FAIL Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json Cache-Control: private, no-store, no-cache, must-revalidate Pragma: no-cache { "token_type":"bearer", "access_token":"aaent0f1dghdbgllbnqwmcqe_hpxfxepnp8gvk8vtj23suwut xdavsnvmftbvpk5thrla6rolxsb7dc_or4ubhccqh7bkzpfrbnlaeupowsrr0l5fn wkdv6dderaj30ul87yolg_sfdgbaznrb7gdg", "expires_in":3600, "scope":"/getaccountinfo /getcustomerinfo", "refresh_token":"aafbzncgphbyu_y4zqq3tj_ofaryv9h_ahjhlmx_zgvggki1 zqne3fjwxm5yhtdsre0ghg8eb98qqvuhr8swsqkgc8_wt5yimdorlpui6pa9ibum6 ZXrq-pn9oR1nUEf_Us" } アクセス トークン発行時に 外部リポジトリーに対してアクセス トークンの失効チェックを行う 外部リポジトリー (Node.js) >node --harmony cache-svr.js cache server running on,, port receive request, /checkrevoke?client_id=oauthclient01&resource_owner=u SER01&tok en_type=az-code&token=aaizi878lono9aec1xqpffwpmsojdsc_ud4-gwizls2h4mxwzaptchy_w EzE48V80jjLgB_JqMAZdp2HV6a1iga8QyMAnttf1cXpR6Ab ag2_awbngk6ssdzci9ggczqb2a, at Th u Mar :10:28 GMT+0900 ( 東京 ( 標準時 )) check revocation not revoked receive request, /clientrevoke?az_code=aaizi878lono9aec1xqpffwpmsojdsc_ud4-gwi ZLs2H4MxwZAPtcHy_WEzE48V80jjLgB_JqMAZdp2HV6a1ig a8qymanttf1cxpr6abag2_awbngk6ssdz ci9ggczqb2a&az_code_ttl=300, at Thu Mar :10:28 GMT+0900 ( 東京 ( 標準時 ) ) cache client revoke info for at undefined and rt undefined 124

125 外部リポジトリーの利用 (9/11) 確認結果 ( 続き ) curl アクセス トークン失効 $ curl -i -k -d "grant_type=urn:ibm:datapower:client:revoke&access_token=aaent0f1 dghdbgllbnqwmcqe_hpxfxepnp8gvk8vtj23suwutxdavsnvmftbvpk5thrla6rol xsb7dc_or4ubhccqh7bkzpfrbnlaeupowsrr0l5fnwkdv6dderaj30ul87yolg_sf DGBAzNRb7gdg" --user OAuthClient01:passw0rd HTTP/ OK X-Backside-Transport: FAIL FAIL Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json Cache-Control: private, no-store, no-cache, must-revalidate Pragma: no-cache { "status":"success" } 外部リポジトリー (Node.js) receive request, /clientrevoke?access_token=aaent0f1dghdbgllbnqwmcqe_hp xfxepnp8 gvk8vtj23suwutxdavsnvmftbvpk5thrla6rolxsb7dc_or 4UbhccQh7BKzPFrbNlaEuPOwSrr0l5fnw kdv6dderaj30ul87yolg_sfdgbaznrb7gdg&access_toke n_ttl=3600, at Thu Mar :12:29 GMT+0900 ( 東京 ( 標準時 )) cache client revoke info for at AAENT0F1dGhDbGllbnQwMcQE_HPxFxePnP8gVK8vtj23SUw u TxdavsNvMFTbvPK5tHRla6ROlxsb7dC_oR4UbhccQh7BKzP FrbNlaEuPOwSrr0l5fnwkdv6DderAJ30U l87yolg_sfdgbaznrb7gdg and rt undefined IDG はアクセス トークン失効要求を受けて 外部リポジトリーに失効情報を連携 125

126 外部リポジトリーの利用 (10/11) 確認結果 ( 続き ) curl アクセス トークン検査 $ curl -i -k -d "grant_type=urn:ibm:datapower:validate&access_token=aaent0f1dghdb GllbnQwMcQE_HPxFxePnP8gVK8vtj23SUwuTxdavsNvMFTbvPK5tHRla6ROlxsb7d C_oR4UbhccQh7BKzPFrbNlaEuPOwSrr0l5fnwkdv6DderAJ30Ul87YOlG_sFDGBAz NRb7gdg" --user OAuthClient01:passw0rd HTTP/ OK X-Backside-Transport: FAIL FAIL Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json Cache-Control: private, no-store, no-cache, must-revalidate Pragma: no-cache { "valid":false } 外部リポジトリー (Node.js) receive request, /checkrevoke?client_id=oauthclient01&resource_owner=u SER01&tok en_type=access_token&token=aaent0f1dghdbgllbnqw McQE_HPxFxePnP8gVK8vtj23SUwuTxdav snvmftbvpk5thrla6rolxsb7dc_or4ubhccqh7bkzpfrbnl aeupowsrr0l5fnwkdv6dderaj30ul87yo lg_sfdgbaznrb7gdg, at Thu Mar :13:41 GMT+0900 ( 東京 ( 標準時 )) check revocation revoked by client IDG はアクセス トークン検査要求を受けて 外部リポジトリーに失効情報を確認 126

127 外部リポジトリーの利用 (11/11) 127 確認結果 ( 続き ) curl 失効させたアクセス トークンによるリソース アクセス $ curl -i -k -H "Authorization:Bearer AAENT0F1dGhDbGllbnQwMcQE_HPxFxePnP8gVK8vtj23SUwuTxdavsNvMFTbvPK5t HRla6ROlxsb7dC_oR4UbhccQh7BKzPFrbNlaEuPOwSrr0l5fnwkdv6DderAJ30Ul8 7YOlG_sFDGBAzNRb7gdg" HTTP/ Error Content-Type: text/html X-Backside-Transport: FAIL FAIL Connection: close <!DOCTYPE HTML PUBLIC "-//W3C/DTD HTML 4.0 Transitional//EN"> <!-- Licensed Materials - Property of IBM IBM WebSphere DataPower Appliances Copyright IBM Corporation All Rights Reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. --> <html> <title>connectivity Error</title> <body> <h1>web Application Gateway Error</h1><P/> <h2><font color="red">gateway detected an error during processing of service request.</font></h2><p/> <h2>please contact the service administrator.</h2> </body> </html> 外部リポジトリー (Node.js) receive request, /checkrevoke?client_id=oauthclient01&resource_owner=u SER01&tok en_type=access_token&token=aaent0f1dghdbgllbnqw McQE_HPxFxePnP8gVK8vtj23SUwuTxdav snvmftbvpk5thrla6rolxsb7dc_or4ubhccqh7bkzpfrbnl aeupowsrr0l5fnwkdv6dderaj30ul87yo lg_sfdgbaznrb7gdg, at Thu Mar :14:45 GMT+0900 ( 東京 ( 標準時 )) check revocation revoked by client IDG はリソース アクセス時に外部リポジトリーに対して失効チェックを行う

128 外部リポジトリー利用時の考慮点 外部リポジトリー側で以下の検討が必要 データベースの性能 ( トークンのレコード件数 パフォーマンスなど ) 冗長化 128

129 参考資料 IBM developerworks Implementing OAuth on IBM WebSphere DataPower Appliances 08_rasmussen/1208_rasmussen.html Knowledge Center IBM DataPower Gateway dp.doc/welcome.html IETF RFC 6749:The OAuth 2.0 Authorization Framework 225&cm_mc_sid_ =

130 Copyright IBM Corporation All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others. 130