資格証明コレクションおよびログインの理解

23.1 Access Manager資格証明コレクションの概要

Access Managerでは、認証処理で資格証明コレクション用に2つのメカニズムを提供します。

デフォルトの埋込み資格証明コレクタ(ECC)は、Access Managerサーバーとともにインストールされるため、追加のインストールや設定ステップなしで使用できます(ただし、「グローバル・パスワード・ポリシーの管理」で説明しているグローバル・パスワード・ポリシーを除きます)。

ユーザーをポリシー強制点から資格証明コレクタにリダイレクトするメカニズムは、HTTP上のフロント・チャネル・プロトコル専用です。このプロトコルは、現時点では、リクエストのコンテキストと、問合せ文字列に対する認証レスポンスを提供します。
OAM Webゲートは、オプションの外部資格証明コレクタ(DCC)に切り替えるための1つのスイッチが用意されています。DCCを使用すると、アプリケーション層ではなくWeb層でエンドユーザー・リクエストを終了できます。

ノート:

OAM 12cで導入された新機能にはECCを使用することをお薦めします。OAM 12cで導入された新機能の一部では、DCCがサポートされていません。たとえば、OpenIDConnectではDCCの使用がサポートされていません。
ECCとDCCのいずれによってもセキュアなデプロイメントが可能になりますが、多層防御アプローチでは、セキュリティの脆弱性(DDOS、スロットル、アプリケーション・ファイアウォール)をアップストリームのアプリケーション・デリバリ層で処理することが求められます。一般的なエンタープライズ・デプロイメントの場合、堅牢なアップストリーム機能が存在するため、未認証の接続をWeb層で終了するという潜在的な利点は、DCCの制限により、最小限しか得られません。

資格証明コレクションの2つのメカニズムの詳細な比較は、「認証方式と資格証明コレクタの理解」を参照してください。

シングル・サインオンのログイン処理は、ユーザーが有効なユーザーかどうかと、セッション状態がアクティブまたは非アクティブ(初回のユーザーまたはユーザー・セッションの期限が切れている場合)かを決定します。セッション管理サポートでは、セッション・コンテキストおよびユーザー・トークンを検索、保持および消去します。次の各項で詳しく説明します。

23.1.1 セルフサービス・プロビジョニング・アプリケーションを使用したログイン・プロセスの概要

プロビジョニングは、Access Managerのセッションを作成しません。新しいユーザーがセルフサービス・プロビジョニング・アプリケーションを使用してアカウントを作成すると、ユーザーはアプリケーションにアクセスするときにユーザーIDとパスワードを再度求められます。

保護されているアプリケーションはAccess Managerに転送され、Access Managerがユーザーの資格証明をリクエストします。たとえば、Oracle Identity GovernanceがAccess Managerで保護されている場合、ユーザー・リクエストは、資格証明の入力をリクエストするAccess Managerにリダイレクトされます。

ノート:

成功の結果と失敗の結果は、「Access Managerで保護されたリソースを使用したログイン・プロセスの概要」"で説明するとおりです。

23.1.2 Access Managerで保護されたリソースを使用したログイン・プロセスの概要

ユーザーが保護されたリソースに初めてアクセスすると、リソースの認証スキームと認証レベルに基づいて資格証明が求められます。通常は、ユーザーIDとパスワードが必要になります。

失敗: ユーザーIDまたはパスワードの入力に間違いがあると、認証は失敗します。ユーザーは認証されずに、資格証明を求める別のプロンプトが表示されます。

Oracle Access Managerでは、OAMサーバー内のECCのみが使用可能でした。Access Manager は、デフォルトでECCをサポートします。ただし、Access Managerでは、外部資格証明コレクタ(DCC)として使用するように、OAM Webゲートを構成することもできます。DCC対応のWebゲートは、リソースWebゲートと分離(または結合)できます。

ECCとDCCは、どちらもフォームのログイン、エラー、ログインの再試行を含む認証フローを提供します。これらは、SecurIDとサーバーのアフィニティの他、パスワード・ポリシーの実施や、資格証明が一度に提供されない、動的、マルチステップ、反復および変数の認証(マルチステップ認証)を提供します。カスタマイズ可能な認証フローには、認証プラグインを含めることができます。この認証プラグインは、そのプラグインとOAMプロキシ、資格証明コレクタ間のコントラクトを持つもの、そのプラグインとログイン・アプリケーション間のコントラクトを持つもの、資格証明コレクタとログイン・アプリケーション間のコントラクトを持つものがあります。

どちらの(または両方の)資格証明コレクタを使用するかを決定するときには、次の事項について検討します。

共存: ECCとDCCの共存を許可すると、ECCまたはDCCに対応した構成の認証スキームとポリシーを使用できるようになります。これにより、ECC (たとえば、Oracle Access Managementコンソール)に依存するリソースにフォールバック・メカニズムを使用できるようになります。
ECCを無効にする: ECCを無効にすると、ECCメカニズム(たとえば、Oracle Access Managementコンソール)に依存するリソースへのアクセスを完全に禁止することになります。

表23-1に、詳細へのリンクを示します。

表23-1 Access Managerで保護されたリソースへのログイン処理

ログイン処理の項目	参照
OAMエージェントとECCの使用	「OAMエージェントとECCによるSSOログイン・プロセスの概要」
OAMエージェントとDCCの使用	「OAMエージェントとDCCによるSSOログイン・プロセスの概要」

その他のエージェントまたは混在するエージェント・タイプの使用	混在しているエージェント・タイプがサポートされています。各エージェント・タイプの処理は同じです。
Oracle ADFセキュリティを使用したアプリケーションのログインおよび自動ログイン	Oracle Platform Security Services (OPSS)は、Oracle WebLogic Serverの内部セキュリティ・フレームワークで構成されます。Oracle WebLogic Serverでは、Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Access Manager SSOと統合して、ユーザー認証にOPSS SSOを使用するWebアプリケーションを実行できます。詳細は、「Oracle ADFアプリケーションとAccess Manager SSOの統合」を参照してください。

23.2 OAMエージェントとECCによるSSOログイン・プロセスの概要

Access Managerは、顧客が指定した認証方式で各ユーザーを認証してアイデンティティを決定し、ユーザー・アイデンティティ・ストアに格納されている情報を利用します。

このトピックでは、リソースを保護するOAMエージェント(リソースWebゲート)とともにデフォルトの埋込み資格証明コレクタを使用していることを前提にしています。

Access Managerの認証では、いくつかの認証方法と複数の認証レベルをサポートしています。より厳密な認証方式に対応する高いレベルの認証を要求すると、様々な機密度のリソースを保護できます。

ユーザーが保護されているアプリケーションにアクセスしようとすると、Access Managerがリクエストを受け取り、SSO Cookieの有無を確認します。

ユーザーを認証してユーザー・コンテキストおよびトークンを設定した後、Access ManagerはSSO Cookieを設定して、SSOサーバー・キーでCookieを暗号化します(このキーは、SSOエンジンでのみ復号化できます)。

認証の成功および失敗に対して指定されているアクション(Access Manager 11gのレスポンス)に応じて、ユーザーが特定のURLにリダイレクトされたり、ヘッダー変数またはCookie値を介してユーザー情報が他のアプリケーションに渡されたりします。

認可ポリシーおよび確認結果に基づいて、リクエストした内容へのユーザーのアクセスが許可または拒否されます。ユーザーのアクセスが拒否されると、ユーザーは(Webゲート登録で管理者が指定した)別のURLにリダイレクトされます。

図23-1は、ポリシーの評価、ユーザーのアイデンティティの検証、保護されたリソースへのユーザーの認可および保護されたリソースの使用に含まれるプロセスを示しています。この例は、OAMエージェント・フローを示しています。12c Webゲート/アクセス・クライアントの場合は、多少異なります。

図23-1 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン

「図23-1 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン」の説明

プロセスの概要: 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン処理

ユーザーがリソースをリクエストします。
Webゲートは、ポリシー評価のリクエストをAccess Managerに転送します。
Access Manager:
- SSO Cookieの有無をチェックします。
- ポリシーをチェックして、リソースが保護されているかどうか、保護されている場合はどのような方法で保護されているかを判断します。
Access Managerサーバーは、決定をログに記録して返します。
WebGateは、次のように応答します。
1. 保護されていないリソース: リソースがユーザーに提供されます。
2. 保護されているリソース:
  
  リクエストが資格証明コレクタにリダイレクトされます。
  
  認証ポリシーに基づくログイン・フォームが提供されます。
  
  認証処理が開始されます。
ユーザーが資格証明を送信します。
Access Managerは、資格証明を検証します。
Access Managerはセッションを開始し、次のホストベースCookieを作成します。
- エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用して各OAM Webゲートで設定されたOAMAuthnCookie。
  
  ノート: 有効なCookieがセッションに必要です。
- OAMサーバーに1つ: OAM_ID
Access Managerは、成功または失敗をログに記録します。
資格証明コレクタがWebGateにリダイレクトされ、認可処理が開始されます。
Webゲートは、ポリシーの検索、ユーザーのアイデンティティとの比較およびユーザーの認可レベルの決定をAccess Managerに求めます。
Access Managerは、ポリシー決定をログに記録し、セッションCookieを確認します。
OAMサーバーが認可ポリシーを評価して、結果をキャッシュします。
OAMサーバーが判定をログして返します。
WebGateは、次のように応答します。
- 認可ポリシーでアクセスを許可すると、目的の内容またはアプリケーションがユーザーに提供されます。
- 認可ポリシーによってアクセスが拒否された場合、ユーザーは、管理者が決定した別のURLにリダイレクトされます。

23.3 OAMエージェントとDCCによるSSOログイン・プロセスの概要

外部資格証明コレクタとは、デプロイメント内で追加の資格証明コレクション機能を使用するように構成された、Webゲートのことです。

DCC Webゲートでもアプリケーションを保護するかどうかによって、2つのデプロイメント・タイプが存在します。

表23-2に、DCCがサポートされるデプロイメントを示します。

表23-2 DCCデプロイメントのサポート

デプロイメント・タイプ	説明
独立したDCCとリソースWebゲート	アプリケーションを保護するWebゲートが、一元化されたDCCとは別に独立的に管理されている分散デプロイメントです。この内容は、次のようになります。 2つ以上のリソースWebゲートを使用し、認証はDCC対応WebゲートにリダイレクトユーザーエージェントとDCCとの間のHTTPSを有効にします(ただし、一部またはすべてのリソースWebゲートとのHTTPSは有効にしません)。資格証明コレクションがDCC Webゲートに外部化されて一元化されている場合、ユーザーエージェントと他のWebゲートとの接続では、ユーザー資格証明、および他のWebゲートによって保護されているリソースへのアクセスを取得するために使用できるセッション・トークンが伝送されることはありません。これにより、これらのリンクでSSLを使用しないために公開される情報が大幅に減少し、デプロイメントによっては許容可能なトレードオフになります。 OHSインスタンスの分離: DCCをリソースWebゲートと(同じホストまたは別のホスト上の)別のOHSインスタンスにインストールします。リソースWebゲートの認証スキームのチャレンジ・リダイレクトURLを、DCCを指すように定義します。リソースWebゲートのlogoutRedirectUrlを、DCCログアウト・スクリプト/ページを指すように定義します(リソースWebゲートへのログアウト・コールバックは、ログアウト時に呼び出されます)。関連項目: 図23-2
DCCとリソースWebゲート一体化	構成と処理のオーバーヘッドが最小になる、合理化されたデプロイメントです。 DCC Webゲートは、アプリケーション・リソースを保護するリソースWebゲート(ポリシー強制点)とDCCの両方として使用できます。この場合、フロントチャネル・リダイレクションやフロントチャネル処理はありません。 DCCをリソースWebゲートと同じOHSインスタンス(同じホスト)にインストールします。合理化された構成: チャレンジ・リダイレクトURLは空にします。 logoutRedirectUrlは必要ありません。また、ログアウト・コールバックは必要ありません。関連項目: 図23-3

デプロイメント・タイプ

説明

独立したDCCとリソースWebゲート

アプリケーションを保護するWebゲートが、一元化されたDCCとは別に独立的に管理されている分散デプロイメントです。この内容は、次のようになります。

2つ以上のリソースWebゲートを使用し、認証はDCC対応Webゲートにリダイレクト

ユーザーエージェントとDCCとの間のHTTPSを有効にします(ただし、一部またはすべてのリソースWebゲートとのHTTPSは有効にしません)。

資格証明コレクションがDCC Webゲートに外部化されて一元化されている場合、ユーザーエージェントと他のWebゲートとの接続では、ユーザー資格証明、および他のWebゲートによって保護されているリソースへのアクセスを取得するために使用できるセッション・トークンが伝送されることはありません。これにより、これらのリンクでSSLを使用しないために公開される情報が大幅に減少し、デプロイメントによっては許容可能なトレードオフになります。

OHSインスタンスの分離: DCCをリソースWebゲートと(同じホストまたは別のホスト上の)別のOHSインスタンスにインストールします。
リソースWebゲートの認証スキームのチャレンジ・リダイレクトURLを、DCCを指すように定義します。
リソースWebゲートのlogoutRedirectUrlを、DCCログアウト・スクリプト/ページを指すように定義します(リソースWebゲートへのログアウト・コールバックは、ログアウト時に呼び出されます)。

23.4 DCC対応のOAM Webゲートと認証ポリシーの構成

管理者は、DCCの資格証明操作の有効化、パスワード・ポリシーのDCCフォームの更新、認証ポリシーへのPasswordPolicyValidationSchemeの追加、および集約フェデレーション・フローでのDCCの使用が可能です。

次のステップでは、DCCで使用するためにWebゲートと認証ポリシーを構成する方法について説明します。各ステップには、該当する項へのリンクが示されています。

DCCの資格証明操作の有効化には、次の両方の構成ステップが説明されています。

リソースWebゲートと一体化されたDCC: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にします。

独立したDCCとリソースWebゲート: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にして、「ログアウト・リダイレクトURL」にDCCのlogout.plを設定します。
パスワード・ポリシーのDCCフォームの検索と更新
DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加には、次の両方の構成ステップが説明されています。

一体化されたDCC/リソースWebゲート: 一体化されたDCC/リソースWebゲート・アプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。

独立したDCCとWebゲート: 独立したリソースWebゲートのアプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。
「DCCによるフェデレーション・フローのサポート」では、DCCをフェデレーションのフローに取り込むステップを説明しています。

ノート:

ECCを使用している環境の場合は、「パスワード・ポリシー構成の完了」を参照してください。

23.4.1 DCCの資格証明操作の有効化

独立したDCCを使用しているか、DCCとリソースWebゲートを一体化しているかにかかわらず、DCCのOAMエージェント登録ページで「資格証明コレクタ操作の許可」を有効にする必要があります。

DCCとリソースWebゲートが独立している場合は、リソースWebゲート登録ページを編集して、ステップ3で示すように、「ログアウト・リダイレクトURL」の値がDCCのlogout.plとなるように設定する必要があります。

次の手順は、デプロイメントでオープン・モード通信を使用していると仮定しています。デプロイメントで簡易モードまたは証明書モードの通信を使用している場合は、ステップ4の実行時に適切なアーティファクトをコピーしてください。

前提条件

Oracle Access Managementコンソールの「Access Manager」セクションでSSOエージェントをクリックして、DCCとして動作するOAM Webゲートの登録ページを検索して開きます。
DCC Webゲート登録: 「資格証明コレクタ操作の許可」を選択し、「適用」をクリックして、ステップ4と5を実行します。

ノート:

DCCをリソースWebゲートと一体化している場合は、ステップ3をスキップしてください。
独立したリソースWebゲート: リソースWebゲート登録を編集して、「ログアウト・リダイレクトURL」にDCCのlogout.pl (表24-3)を設定し、「適用」をクリックして、ステップ4と5を実行します。

AdminServer (コンソール)ホストからエージェント構成ファイル(簡易モード・ファイルまたは証明書モード・ファイルを含む)をエージェント・ホストにコピーします。たとえば:

エージェントおよびアーティファクト	アーティファクト
OAM Webゲート/アクセス・クライアント ObAccessClient.xmlとcwallet.sso	コピー元: AdminServer (コンソール)ホスト $DOMAIN_HOME/output/$Agent_Name/ コピー先: エージェント・ホストの$12cWG_install_dir/webgate/config
簡易または証明書モード	エージェント・ホストにコピー: $12cWG_install_dir/webgate/config aaa_key.pem aaa_cert.pem aaa_chain.pem password.xml 関連項目: 「通信の保護」

エージェントおよびアーティファクト

アーティファクト

OAM Webゲート/アクセス・クライアント

ObAccessClient.xmlとcwallet.sso

コピー元: AdminServer (コンソール)ホスト

$DOMAIN_HOME/output/$Agent_Name/

コピー先: エージェント・ホストの$12cWG_install_dir/webgate/config

簡易または証明書モード

エージェント・ホストにコピー: $12cWG_install_dir/webgate/config

aaa_key.pem
aaa_cert.pem
aaa_chain.pem
password.xml

23.4.2 パスワード・ポリシーのDCCフォームの検索と更新

Access Managerは、DCCに対するユーザー操作のためにいくつかの動的なページを提供します。

23.4.3 DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加

保護されたリソースの認証ポリシーでDCC認証スキームを使用できます。

実行するステップは、デプロイメントのタイプに応じて異なります。

一体化されたDCC/リソースWebゲート: ステップ1を実行して、一体化されたDCC/リソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。
独立したリソースWebゲート: ステップ3を実行して、独立したリソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。

ステップ2は、DCCのデプロイメント・タイプにかかわらず実行してください。デフォルトでは、ログインおよびログアウトのフォームは、OHSの/httpd.conf/webgate.confを通じて除外されるため、これらのフォームをポリシーから除外する必要はありません。ただし、Chromeブラウザの場合は、明示的にasync favicon.icoリクエストを除外する必要があります(このリクエストは、DCCCtxCookieを無視します)。

ノート:

この例では、「パスワード・ポリシー認証の構成」のDCCに設定されたPasswordPolicyValidationSchemeを参照しています。

前提条件

パスワード・ポリシーのDCCフォームの検索と更新

一体化されたDCC/リソースWebゲート: DCCアプリケーション・ドメインを開きます。
- ポリシーの構成
- アプリケーション・ドメイン
- DCCDomain
1. 認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。
2. このポリシーにDCC認証スキームを追加します(「特定のリソースに対する認証ポリシーの定義」を参照してください)。
  - PasswordPolicyValidationScheme (DCC認証スキーム)
3. Chromeブラウザを使用する場合は、ステップ2を実行します。それ以外の場合は、ステップ4に進みます。
Chromeブラウザ: 次の手順を実行して、DCCDomainで/favicon.icoを追加します。
1. DCCDomainで、「リソース」タブをクリックします。
2. HTTPリソースの/favicon.icoを見つけて開きます(または、「新規リソース」ボタンをクリックして、このリソースを追加します)。
3. 「リソースURL」を確認または編集して、次のようにします。
```
/favicon.ico
```
4. 「保護」セクションで、「保護レベル」リストから「除外」を選択して、「適用」をクリックします。
5. ステップ4に進みます。
独立したWebゲート: リソースWebゲート・アプリケーション・ドメインを開きます。
- ポリシーの構成
- アプリケーション・ドメイン
- ResourceWGDomain
1. 認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。
2. このポリシーにDCC認証スキームと、オプションの失敗URLを追加します(指定しない場合、失敗URLはデフォルトのエラー・ページを表示します)(「特定のリソースに対する認証ポリシーの定義」を参照してください)。
  - DCC認証スキーム
  - 失敗URL (オプション)
3. Chromeブラウザを使用する場合は、ステップ2を実行します。それ以外の場合は、ステップ4に進みます。
Webサーバーを再起動して、「パスワード・ポリシー構成の完了」に進みます。

関連項目:

「外部資格証明コレクタが有効化されたWebゲートを使用する場合のログアウトの構成」

23.4.4 DCCによるフェデレーション・フローのサポート

DCCは、Access Managerサーバーに対するパブリック・エンドポイントとして動作するように機能が拡張されています。DCCへのHTTPリクエストは、NAPを介してAccess Managerサーバーのプロキシ・モジュールにトンネリングされます。DCCプロファイルのTunneledUrlsパラメータで定義されているリクエストのみがトンネリングされます。JSPのページおよびサーブレットがAccess Managerサーバーで実行され、レスポンスがトンネリングによりDCCに返されます。実質的に、エンド・ユーザーが通信する相手はDCCのみとなります。

ノート:

WebGateがDCCとして構成されていてフェデレーテッド・フローが使用中の場合、DCC WebGateを使用してリソースを保護できません。リソースを保護するには、別のWebGateを構成して使用する必要があります。認証および認可リクエストがOAMサーバーにトンネリングされ、ECCログイン・フォームがトンネリングされてユーザーのブラウザに表示されます。

DCCを集約フェデレーション・フローに使用する場合は、次のステップを手動で実行します。

次の内部リソースを、除外ではなくパブリックとして構成します。
```
/oamfed/.../*
/oam/.../*
/.../*
```
DCC Webゲートのログアウトの値を、有効なDCC Webゲート・ログアウトURLに設定します。たとえば、/oamsso-bin/logout.plです。
DCCエージェントのエントリを更新します。次に示すエントリを、Access Manager管理コンソールを使用して「ユーザー定義パラメータ」のリストに追加してください。
```
TunneledUrls=/oam,/oamfed
```
「OAPトンネリングの構成」を参照してください。
OAMパブリック・エンドポイント・エントリを、DCC Webゲートを指すように更新します。

「Access Managerの設定」で、「OAMサーバー・ホスト」、「OAMサーバー・ポート」および「OAMサーバー・プロトコル」をOHS/DCCに関連する値に設定し、「適用」をクリックします。

ノート:

または、RESTパラメータを変更せずにチャレンジ・リダイレクトURLを変更することにより、単一の認証スキームを、DCC Webゲートをポイントするように更新することもできます。
(該当する場合は)「フェデレーション設定」で「プロバイダID」の値を更新し、エンドポイントの変更によって生じた新しいメタデータをすべてのフェデレーション・パートナに再配信します。
contextTypeを'External'に設定します。

この設定の詳細は、「認証スキームおよびページ」を参照してください。

23.5 Oracle Accessプロトコルを介したDCCからAccess Managerへのトンネリング

Access Managerは、Oracle Accessプロトコル(OAP)を介したHTTP通信をサポートしています。この場合、DCCとして構成されたWebゲートは、Access Manager認証時の資格証明コレクションにECCサーブレットを使用します。

後続の項で詳細を示します。

ノート:

DCCの詳細は、「埋込み資格証明コレクタと外部資格証明コレクタ」を参照してください。

23.5.1 OAPによるDCCトンネリングの仕組み

トンネリング・プロセスは、DCC Webゲートでのみ機能します。

図23-4は、トンネリング・プロセスの仕組みを示しています。

図23-4 DCCによるOAPトンネリング

「図23-4 DCCによるOAPトンネリング」の説明

次のステップでは、OAPトンネリング・プロセスについて詳しく説明します。

トンネリングするURLがDCC Webゲート・プロファイルで構成されます。
これと同じURLが、Access ManagerサーバーのサーブレットまたはJSPページにマップされます。
トンネリングされたURLにアクセスすると、WebゲートがHTTPリクエストを捕捉してOAPリクエストに変換します。
OAPリクエストがAccess Managerサーバーに転送されます。
Access Managerサーバー(OAMプロキシ)がOAPリクエストを受信して、トンネル・プロキシに渡します。
トンネル・プロキシはOAPリクエストをHTTPServletRequestに変換し、対応するサーブレット(JSPの場合はコンパイル済サーブレット)を呼び出します。
レスポンスが再びOAPメッセージに変換されて、OAPエンド・ポイントに渡されます。
OAPエンド・ポイントは、変換されたOAMメッセージを使用してWebゲートに応答します。
Webゲートは、OAPメッセージを再びHTTPレスポンスに変換します。
Webゲートは、HTTPレスポンスをコール元(ブラウザ)に提供します。

23.5.2 OAPトンネリングの構成

OAPトンネリングを構成するには、Webゲートをインストールし、DCCとしてのAccess Managerサーバーと連動するように構成しておく必要があります。

また、Access ManagerエンドポイントをAccess Managerサーバーにデプロイしておく必要があります。これらの前提条件が満たされていることを確認したら、TunneledUrls=<URL>,<URL1>という形式を使用して、ユーザー定義のパラメータを、トンネリングするすべてのURLを定義するWebゲート・プロファイルに追加します。たとえば:

TunneledUrls=/oam,/sampleapp

最後に、トンネリングしたURLを認証ポリシーで保護します。詳細は、「認証コンポーネントと共有ポリシー・コンポーネントの管理」を参照してください。

23.6 X509認証のためのDCC Webゲートの構成

DCC用にWebゲートを構成し、それをX509認証で使用するためにSSLに変換します。

23.6.1 WebLogic Serverの構成

次の各項の手順を使用して、X509認証のためのWebLogic Serverを構成します。

23.6.1.1 サーバーおよびトラスト・ストアの作成

これらはWebLogic Serverに共通の手順です。

サーバー証明書を作成します。

Oracle Access Management 11gがデプロイされるWLSドメインのサーバー証明書およびキーを作成します。これには、証明書のリクエスト(共通名はOAMサーバー・マシン名です)が必要で、証明書に署名してP12形式に変換します。サーバー証明書は、証明書ユーティリティを使用して作成および署名できます。
keytoolを使用してサーバー・ストアおよびトラスト・ストアを作成します。

詳細は、「OAMサーバーとWebゲート間の通信の保護」を参照してください。

23.6.1.2 WebLogic Serverインスタンスの構成

WebLogicコンソールを使用して、SSLおよびクライアント証明書が有効になるようにWebLogic Serverのインスタンスを構成します。

SSLおよびクライアント証明書を有効にするサーバー・インスタンスに移動します。

図23-5 SSLの有効化

「図23-5 SSLの有効化」の説明
図23-5に示すように、「SSLリスニング・ポートの有効化」チェック・ボックスを選択し、ポート番号を指定します。
「キーストア」タブでサーバーおよびトラスト・キーストアのパスを指定します。

図23-6 キーストアの構成

「図23-6 キーストアの構成」の説明
「SSL」タブで秘密キーの別名の詳細を追加します。

別名は、「サーバーおよびトラスト・ストアの作成」のサーバー・ストア名として指定したのと同じ名前です。

図23-7 秘密キーの別名の追加

「図23-7 秘密キーの別名の追加」の説明
図23-8に示すように、「SSL」タブに「拡張」オプションが表示され、構成を行います。

図23-8 SSL拡張オプション

「図23-8 SSL拡張オプション」の説明

23.6.1.3 ユーザー証明書の作成

ユーザー証明書を.p12形式で作成して、ブラウザにインストールできます。

次のOpenSSLコマンドを実行します。

openssl req -config openssl.cnf -new -out weblogic.csr

証明書の詳細を指定します。共通名は、証明書がリクエストされるユーザーの名前です。
openssl x509 -req -md5 -CAcreateserial -in weblogic.csr -days 180 -CA

F:\openssl\simpleCA\ca.pem -CAkey F:\openssl\simpleCA\ca-key.pem -extfile

F:\openssl\openssl.cnf -out weblogic.pem
openssl rsa -in privkey.pem -out weblogic.key
openssl pkcs12 -export -in weblogic.pem -inkey weblogic.key -out user1k1.p12
.p12形式の証明書の出力をブラウザにインストールします。

23.6.1.4 ルートCA証明書の追加

SSL対応のWebLogic Serverに使用する証明書ユーティリティのルートCA証明書を追加できます。

(この例では、OpenSSL証明書ユーティリティが使用されています。)ルートCA証明書は、次のWebLogicディレクトリにある.oamkeystoreおよびamtruststoreファイルに追加する必要があります。

$DOMAIN_HOME/base_domain/config/fmwconfig

次のステップの説明に従って、WebLogicの.oamkeystoreおよびamtruststoreファイルのパスワードを取得します:
1. コンテキストURL (/em) を使用してOracle Enterprise Manager Fusion Middleware Control 12cコンソールにログインします。たとえば、http://<HOST>:<PORT>/emです。
2. 「システムMBeanブラウザ」ページに移動するには、「Weblogicドメイン」ドロップダウンをクリックし、「システムMBeanブラウザ」を選択します。
3. 次のステップの説明に従って、credentialFromUDM操作を検索します:
  1. 「システムMBeanブラウザ」の双眼鏡アイコンを選択します。
  2. MBean名をOperationsに変更し、テキストcredentialFromUDMを入力します。[Enter]キーを押して検索します。
  3. 下にスクロールしてcredentialFromUDM操作のリンクを選択し、対応するページを開きます。
4. .OAMKeystoreパスワードを取得するには、次のパラメータ値を入力して、「呼出し」をクリックします。
  - p1 = oracle.oam.OAMStore (mapname)
  - p2 = JKS (key)
  パスワードは、「戻り値」ペインに表示されます。

keytoolコマンドを使用して、ルートCA証明書を.oamkeystoreおよびamtruststoreファイルに追加します。

–storepassの値は、前述のステップで取得したパスワードです。たとえば:

./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore /scratch/Oracle/Middleware/user_projects/domains/base_domain/config/fmwconfig/.oamkeystore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jceks
 
./keytool -importcert -alias ROOT_CA -file /scratch/CA/ca.pem -keystore /scratch/Oracle/Middleware/user_projects/domains/base_domain/config/fmwconfig/amtruststore -storepass oru8nd3hhd4t4nrmh6unhv825b -storetype jks

23.6.2 DCCのためのWebゲートの構成

DCC用にWebゲートを構成できます。この手順の一部として、LDAPScheme_DCC認証スキームも作成します。

構成ステップにはOracle Access Managementコンソールを使用します。この手順では、プロファイルを作成するWebゲートがインストール済であることを前提とします。

ABC_WG1 on http://<host>:7778/index.htmlなどの名前のOAM Webゲート・プロファイルを構成します。
XYZ_WG1_DCC on http://<host>:7779/index.htmlなどの名前のOAM Webゲート・プロファイルを構成します。

このWebゲートは認証Webゲートとして機能します。
XYZ_WG1_DCC Webゲート・プロファイルに移動し、「資格証明コレクタ操作の許可」オプションを選択します。

これにより、DCCとして使用するWebゲートが構成されます。
LDAPScheme認証スキームのコピーを作成して次の値を変更し、新しい認証スキームを作成します。

次の値のみを変更し、その他のパラメータ名はそのままにします。
1. LDAPScheme_DCCと名前を付けます。
2. チャレンジ・リダイレクトURLはhttp://<host>:<port>/ (http://<host>:7779/)です。
3. チャレンジURL: /oamsso-bin/login.pl
ABC_WG1アプリケーション・ドメインに移動して、次を実行します。
1. 「認証ポリシー」に移動します。
2. 「認証ポリシー」(保護されたリソース・ポリシー)を選択します。
3. 新しく作成された認証スキームLDAPScheme_DCCを選択します。
ポート7779を使用するOracle HTTP Serverを再起動します。
保護されたリソース(http://<host>:7778/index.html)にアクセスします。

認証Webゲート・サーバー(ポート7779)からチャレンジ・ページを取得する必要があります。有効な資格証明を指定すると、ポート7778サーバーのリソースが表示されます。

23.6.3 SSLへのDCC Webゲートの変換

DCC Webゲート・インスタンスをSSLに変換できます。

次の各項で詳しく説明します。

23.6.3.1 サーバー証明書の生成

Oracle Wallet Manager (OWM)を使用して、サーバー証明書を生成できます。

OWMを使用して、ウォレットを作成します。
1. OWMを起動します。
```
$ <webtier>/bin/owm
```
2. ウォレット」→「新規」を選択し、画面の指示に従って証明書リクエストを作成します。
3. 作成したウォレットをアクセス可能な場所に保存し、後で参照できるようにパスを書き留めておきます。
4. 「自動ログイン」オプションを選択して、ウォレットを再度保存します。
OWMを使用し、サーバー・リクエスト・ファイルをserver.csrとして作成してエクスポートします。
1. 「操作」→「証明書リクエストのエクスポート」を選択します。
2. server.csrとして保存します。
server.csrに署名し、ユーザー証明書server.pemを生成します。

次のようにOpenSSLユーティリティを使用できます。
```
openssl x509 -req -md5 -CAcreateserial -in ohs_server.csr -days 3656 -CA /
  <path>/ca.pem -CAkey /<path>/ca-key.pem -out server.pem
```
ca.pemおよびca-key.pemの値は、クライアント証明書の生成時に使用される値と同じになります。
CA証明書(ca.pem)をOWMにインポートします。
1. 「操作」→「信頼できる証明書のインポート」を選択します。
2. ca.pem(CA証明書)を参照します。
3. CA証明書をインポートしてウォレットを保存します。
server.pemをユーザー証明書としてインポートします。
1. 「操作」→「ユーザー証明書のインポート」を選択します。
2. ステップ3で生成されたserver.pem証明書を参照します。
3. サーバー証明書をインポートしてウォレットを保存します。
Oracle HTTP Server (OHS) ssl.confファイルを編集して、このウォレットを次のように参照します。
```
#Path to the wallet
SSLWallet "/<path to wallet>/wallet"
SSLVerifyClient require
```
ssl.confは、<webtier>/<instance_home>/config/ohs/ssl.confにあります。
OHSインスタンスを再起動します。

23.6.3.2 クライアント証明書の生成およびインポート

クライアント証明書を生成およびインポートし、新しいX509認証スキームを作成できます。

「ユーザー証明書の作成」に説明されているステップに従い、ユーザー証明書を作成します。
図23-9に示すように、X509_DCCの名前の新しい認証スキームを作成します。

チャレンジ・リダイレクトURLを追加します。チャレンジURLは空白にする必要があります。

図23-9 新しいX509スキーム

「図23-9 新しいX509スキーム」の説明
<user_cert>.p12をブラウザにインポートします。
保護されたリソースにSSLポート経由でアクセスします。たとえば:
```
https://<ohs_host>:<ohs_port>/index.html
```
使用する証明書を尋ねるポップアップが表示されます。適切な証明書を選択すると、リクエストしたリソースがアクセスされます。