| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
POSTデータの保持/リストア機能は、両方の資格証明コレクタ(ECCまたはDCC)に適用されます。
この項では次のトピックを記載しています:
POSTデータの保持/リストア機能は、アプリケーションに、ユーザーが資格証明(または他のデータ)を入力しているフォームがあり、ユーザーがフォームを送信したときには、セッションの有効期限が切れたり、アイドル・セッション・タイムアウトが発生したり、トークンの有効期限が切れてしまった場合に、効力を発揮する機能です。このような場合、POSTデータの保持/リストアが行われなければ、ユーザーには新しいログイン・フォーム(認証スキームによります)が表示されます。
管理者は、有効期限切れになったユーザーと新しく認証されるユーザーが同じ場合にPOSTデータを保持するようにリソースWebgateを構成できます。表22-31に、POSTデータに対するリソースWebgateのサポートと動作を示します。
ノート:
Access Managerがカスタム・エージェントを使用して認証を行う場合は、認証POSTデータの保持/リストアはサポートされません。
表22-31 POSTデータの保持/リストアに対するリソースWebgateのサポート
| リソースWebゲート | 説明 |
|---|---|
認証スキームのサポート |
LDAP、Basic、Sessionless Basic、X509、WNA |
フォーム・エンコーディングのサポート |
アプリケーション・フォームからポストされるtext/html、text/plain、multipart/form-dataおよびapplication/x-www-form-urlencodedタイプのデータ。 |
保持 |
ファイル・タイプの入力フィールドを除く、元のアプリケーション・フォームからポストされたデータのエンコーディング・タイプ。 |
保証 |
ダウンストリーム・アプリケーションは、元のアプリケーション・フォームからポストされた同じPOSTデータを取得します。 |
制約 |
インバウンド・リクエスト・データまたはインバウンド・フロント・チャネル・メッセージの全体サイズ。コード・デフォルト値をオーバーライドする構成パラメータを設定する必要があります。このパラメータは、アプリケーション単位になります。 |
アプリケーション・データの機密性と整合性の維持 |
リソースWebgateも資格証明コレクタも、アプリケーションPOSTデータの解釈または記録は行いません。 有効期限後、および再認証中、ユーザーが別の資格証明で認証を行った場合、前回のユーザーのPOSTデータはリソースWebgateによってクリアされ、リストアされません。ただし、元のアプリケーション・フォームからポストされていたダウンストリーム・アプリケーションURLへのポストは行われます。 |
保持が無視される場合... メッセージが記録される場合... 標準認証が実行される場合... エラーが表示される場合... |
POSTデータが構成済またはハードコーディングされた制限値より大きい場合、保持は無視されます。 POSTデータが許可された制限値より大きいためにスキップされた場合、メッセージが記録されます。 POSTデータがハードコーディングされた制限値(または構成された値)より大きい場合、標準承認フローが使用されます。 フロント・チャネル・メッセージ・データとアプリケーションPOSTデータの両方が大きい場合、エラーが発生します。 |
POSTデータ・ハンドリングに対する資格証明コレクタのサポート
ECCとDCC
旧11g Webgateと互換性あり
即時使用可能なデフォルト・ログイン・フォーム付きフォームベース認証スキーム用のPOSTデータの保持をサポートします。
次の方法により、認証中、アプリケーションPOSTデータが保持されます。
ユーザーの本人確認
資格証明が無効であったため発生したユーザーの本人再確認
アプリケーションPOSTデータの解釈は行われません。
アプリケーション単位で、デフォルト値をオーバーライドする構成パラメータを使用して、インバウンド・フロント・チャネル・メッセージの全体サイズを制御します。
POSTデータが許可される制限値より大きいためにスキップされた場合、警告が記録されます。
次の場合、アプリケーションPOSTデータの保持は行われません。
認証ポリシーが成功/失敗認証URLで構成されている
パスワード管理(パスワードの有効期限など)が含まれている
Access Managerがカスタム・エージェント経由の認証用に使用されている
ECCのみ
埋込み資格証明コレクタは、外部ログイン・ページによるPOSTデータ・ハンドリングをサポートしません。
DCCのみ
POSTデータはHTTPヘッダー経由で保持され、処理できるPOSTデータ・サイズは8192文字です。
フォームベース認証スキームによるPOSTデータのリストアには、チャレンジ・パラメータTempStateMode=formが必要です。
DCCはカスタム・ログイン・ページをサポートしません。
DCCは、パスワード管理操作中(パスワードの有効期限管理など)、パスワード・ポリシー・プラグイン内のURL_ACTIONがFORWARD以外の値に設定されている場合、POSTデータのリストアをサポートしません。
WNA、Basic、X509などの認証スキームでは、POSTデータ・ハンドリングをサポートしています。
FORMチャレンジ・メソッド(即時使用可能ログイン・ページでサポート)
WNA
Basic
Basic+Sessionless
X509
TAPを使用したOIF、OIM,、OAAM統合
表22-32 認証POSTデータ・ハンドリングに必要なパラメータ
| パラメータ | 説明 |
|---|---|
MaxPostDataBytes |
この認証スキーム・チャレンジ・パラメータは、DCCによるPOSTデータ保持に対してのみ構成します。ログイン・フォームからポストできるPOSTデータの最大サイズを制限します。DCCは、Content-Lengthヘッダーの値と、設定されている制限値とを比較します。 デフォルト: unlimited この認証スキーム・チャレンジ・パラメータは、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限する正の整数値を必要とします。 |
MaxPreservedPostDataBytes |
認証POSTデータの保持に対してこの認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)を構成します。 デフォルト: 8192バイト ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作は8192バイトです。 このパラメータは、Webgateが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
TempStateMode=form DCCのみ |
DCCでのフォームベース認証スキーム用のPOSTデータ・リストアには、チャレンジ・パラメータTempStateMode=formが必要です。フォーム認証スキームに対して、このパラメータが定義されていない場合、値はformになります。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
ChallengeRedirectMaxMessageBytes |
obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webgateパラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。 デフォルト: 8192バイト ノート: obrareq.cgiは、Webgateから資格証明コレクタ(OAMサーバーまたはDCC)にリダイレクトされる問合せ文字列の形式での認証リクエストです。 obrar.cgiは、資格証明コレクタ(OAMサーバーまたはDCC)からWebgateにリダイレクトされる認証レスポンス文字列です。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
PostDataRestoration |
このユーザー定義Webgateパラメータは、リソースWebgateに対する認証POSTデータの保持を開始するために構成します。このパラメータは、 デフォルト値:
関連項目: 「認証POSTデータ・ハンドリングの構成」 |
serverRequestCacheType ECCのみ |
このOAMパラメータは、埋込み資格証明コレクタ(ECC)によってリクエスト・コンテキストを記録するために使用されるメカニズムを定義します。 $DOMAIN_HOME デフォルト: COOKIE POSTデータの保持、長いURLの処理およびフォームベース認証スキームでは、FORMであることが必要です。 関連項目: この表内の |
ユーザーが入力する通常のフォーム・データは数キロバイトであることが前提になっているので、着信リクエストから発生するデータ消費に制限を設けることは一般的な要件になります。フロント・チャネル・プロトコルで転送されるデータも(リクエスト、レスポンスともに)、サイズ・チェックを受けることが必要です。
次の状況について考えてみます。
MaxPostDataBytes認証チャレンジ・パラメータを使用して、バック・チャネル上のOAMサーバーに渡されるデータのサイズを制限します。
DCCが使用されている場合、MaxPostDataBytes認証チャレンジ・パラメータはPOSTデータ全体に対してこのチェックを実行します。
MaxPreservedPostDataBytes認証スキーム・チャレンジ・パラメータを使用して、エンド・ユーザー・アプリケーションからのPOSTデータのサイズを制限します。
MaxPreservedPostDataBytes認証スキーム・チャレンジ・パラメータがこれを処理します。加えて、ユーザー定義Webgateパラメータとしてこれを設定することもできます。
Webgateユーザー定義パラメータChallengeRedirectMaxMessageBytesでobrar.cgiまたはobrareq.cgiのフロント・チャネル・ペイロードのサイズを制限します。
この手順を実行する前に、この項のすべてのPOSTデータについてのトピックに目を通しておく必要があります。認証スキームに明示的な変更を加える必要はありません。
認証スキームを構成します。
Oracle Access Managementコンソールを使用して、目的のスキームを作成するか見つけます(認証POSTデータ・ハンドリング)。
「認証スキーム」ページで、POSTデータ・ハンドリングの値を変更します。
この例では、埋込み資格証明コレクタ(表22-20)とPOSTデータ・ハンドリングに対する値(表22-23)を使用します。
| ECCでのPOSTデータに対する認証スキーム・チャレンジ・パラメータ | DCCでのPOSTデータに対する認証スキーム・チャレンジ・パラメータ |
|---|---|
|
|
「適用」をクリックして変更を送信します。
ECC: ECCを使用する場合は、serverRequestCacheType (oam-config.xml内のOAMパラメータ)を構成します。
管理対象サーバーを停止します。
管理サーバーを停止します。
oam-config.xmlを開いて、serverRequestCacheType値を変更します。
ファイルを保存します。
管理サーバーを再起動します。
管理対象サーバーを再起動します。
POSTデータ・ハンドリング用のWebgateパラメータを構成します。
「システム構成」タブの「Access Manager」セクションで、目的のOAMエージェント登録を作成するか、見つけます。
エージェント登録ページで、POSTデータ・ハンドリングの値を送信します(表22-23)。
| ECCでのユーザー定義Webgate POSTデータ・パラメータ | DCCでのユーザー定義Webgate POSTデータ・パラメータ |
|---|---|
|
|
「適用」をクリックして変更を送信します。
