23 資格証明コレクションおよびログインの理解
この章の内容は次のとおりです。
ノート:
特に明記しないかぎり、この章の情報は、すべてのエージェント・タイプとAccess Manager資格証明コレクタに共通です。
「Access Managerの集中ログアウトの概要」を参照してください。
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エージェントとDCCの使用 |
|
その他のエージェントまたは混在するエージェント・タイプの使用 |
混在しているエージェント・タイプがサポートされています。各エージェント・タイプの処理は同じです。 |
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ゲート/アクセス・クライアントの場合は、多少異なります。
プロセスの概要: 埋込み資格証明コレクタとOAMエージェントを使用するSSOログイン処理
-
ユーザーがリソースをリクエストします。
-
Webゲートは、ポリシー評価のリクエストをAccess Managerに転送します。
-
Access Manager:
-
SSO Cookieの有無をチェックします。
-
ポリシーをチェックして、リソースが保護されているかどうか、保護されている場合はどのような方法で保護されているかを判断します。
-
-
Access Managerサーバーは、決定をログに記録して返します。
-
WebGateは、次のように応答します。
-
保護されていないリソース: リソースがユーザーに提供されます。
-
保護されているリソース:
リクエストが資格証明コレクタにリダイレクトされます。
認証ポリシーに基づくログイン・フォームが提供されます。
認証処理が開始されます。
-
-
ユーザーが資格証明を送信します。
-
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とは別に独立的に管理されている分散デプロイメントです。この内容は、次のようになります。
ユーザーエージェントとDCCとの間のHTTPSを有効にします(ただし、一部またはすべてのリソースWebゲートとのHTTPSは有効にしません)。 資格証明コレクションがDCC Webゲートに外部化されて一元化されている場合、ユーザーエージェントと他のWebゲートとの接続では、ユーザー資格証明、および他のWebゲートによって保護されているリソースへのアクセスを取得するために使用できるセッション・トークンが伝送されることはありません。これにより、これらのリンクでSSLを使用しないために公開される情報が大幅に減少し、デプロイメントによっては許容可能なトレードオフになります。
関連項目: 図23-2 |
DCCとリソースWebゲート一体化 |
構成と処理のオーバーヘッドが最小になる、合理化されたデプロイメントです。 DCC Webゲートは、アプリケーション・リソースを保護するリソースWebゲート(ポリシー強制点)とDCCの両方として使用できます。この場合、フロントチャネル・リダイレクションやフロントチャネル処理はありません。
関連項目: 図23-3 |
独立したDCCとリソースWebgate: 図23-2に、DCCを分離したデプロイメントの例を示します。
このトポロジ(図23-2)は、最大のセキュリティ機密性を備えたシナリオに適した選択肢を示しています。集中資格証明コレクションおよび外部資格証明コレクションの両方が使用されています。アプリケーションを保護するリソースWebゲートは、資格証明コレクションを実行するDCC Webゲートから分離されています。
ユーザーは、公衆回線網から、Access Managerによって保護されているリソースにアクセスします。アプリケーションを保護しているWebゲートは、DMZ内にデプロイされます。DCC WebゲートもDMZ内にデプロイされます。保護されているアプリケーションおよびOAMサーバーのインスタンスは、プライベート・ネットワーク内に配置され、公衆回線網から直接アクセスすることはできません。
DMZ内でDCCを使用すると、サーバー自体への接続に認証済のネットワーク接続のみが許可されます。DCCは、OAM Webゲートに利用できるすべてのバックチャネル通信の特性を継承します(Oracle Accessプロトコルを使用するネットワーク接続)。OAPは、次の機能を提供します。
-
クライアントとサーバーの間のSSL (オプションでサード・パーティによる署名済証明書を使用)
-
クライアントIDおよびパスワードを使用するアプリケーション・レベルの相互認証
-
アプリケーション・レベルで多重化された全二重通信をリクエスト
-
組込みの接続ロード・バランシング/フェイルオーバー機能
DCCは、エージェントから認証リクエストを受信すると、DCC Cookieの存在をチェックします。Cookieが存在しない場合、資格証明コレクションが開始され、チェックが行われて、ユーザーが入力した資格証明が検証のために渡されます。
ノート:
暗号化は、リソースWebゲートからDCCへの方向でのみ行われます。リソースWebゲートとDCCの間の通信はクリア・テキストで行われ、チャネルは暗号化されません。
プロセスの概要: 一体化したDCCとリソースWebゲートによる認証
-
ユーザーが、認証プロセスを開始するリソースへのアクセスをリクエストします。
-
DCCは、フロント・チャネルを通じてログイン・ページにリダイレクトします。
-
ログイン・ページがユーザーに返されます。
-
ユーザーは、資格証明を入力します。この資格証明はアクションURLにポストされます(認証スキームのユーザー定義パラメータについては、表22-25を参照)。
-
認証には、バック・チャネル(OAP)とOAMプロキシが使用されます。
-
認証プラグインがアクティブ化されます。
-
プラグインは、追加の資格証明を収集するためのURLへのリダイレクトをリクエストします。
-
プラグインのリクエストは、DCCに返されます。
-
DCCは、そのURLをリダイレクトして、指定された資格証明を要求します。
-
ブラウザは、リダイレクトに従います。
-
資格証明は、アクションURLにポストされます。
23.4 DCC対応のOAM Webゲートと認証ポリシーの構成
管理者は、DCCの資格証明操作の有効化、パスワード・ポリシーのDCCフォームの更新、認証ポリシーへのPasswordPolicyValidationSchemeの追加、および集約フェデレーション・フローでのDCCの使用が可能です。
次のステップでは、DCCで使用するためにWebゲートと認証ポリシーを構成する方法について説明します。各ステップには、該当する項へのリンクが示されています。
ノート:
ECCを使用している環境の場合は、「パスワード・ポリシー構成の完了」を参照してください。
23.4.1 DCCの資格証明操作の有効化
独立したDCCを使用しているか、DCCとリソースWebゲートを一体化しているかにかかわらず、DCCのOAMエージェント登録ページで「資格証明コレクタ操作の許可」を有効にする必要があります。
DCCとリソースWebゲートが独立している場合は、リソースWebゲート登録ページを編集して、ステップ3で示すように、「ログアウト・リダイレクトURL」
の値がDCCのlogout.plとなるように設定する必要があります。
次の手順は、デプロイメントでオープン・モード通信を使用していると仮定しています。デプロイメントで簡易モードまたは証明書モードの通信を使用している場合は、ステップ4の実行時に適切なアーティファクトをコピーしてください。
前提条件
-
パスワード・ポリシー認証の構成(DCC固有の詳細を使用する場合)
23.4.2 パスワード・ポリシーのDCCフォームの検索と更新
Access Managerは、DCCに対するユーザー操作のためにいくつかの動的なページを提供します。
- Webゲート・ホストでDCCフォームを検索します(表24-3)
: $WEBGATE_HOME/webgate/ohs/oamsso/*,
$WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl
および$WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*
。 - それらの場所は、デプロイする認証スキームのトポロジに応じてカスタマイズします。
- Perlの場所を更新します: Webゲート・ホストの
$WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl
にあるlogin、logoutおよびsecuridスクリプトの最初の行で、Perlの場所を実際の場所と一致するように更新します(表24-3)。 - デフォルト・ページを企業に合せてカスタマイズするか、デフォルト・ページ全体をカスタム・ページと置き換えます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。
- 関連項目: 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」。
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/リソースWebゲート: DCCアプリケーション・ドメインを開きます。
- ポリシーの構成
- アプリケーション・ドメイン
- DCCDomain
-
認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。
-
このポリシーにDCC認証スキームを追加します(「特定のリソースに対する認証ポリシーの定義」を参照してください)。
- PasswordPolicyValidationScheme (DCC認証スキーム)
-
Chromeブラウザを使用する場合は、ステップ2を実行します。それ以外の場合は、ステップ4に進みます。
-
Chromeブラウザ: 次の手順を実行して、DCCDomainで
/favicon.ico
を追加します。-
DCCDomainで、「リソース」タブをクリックします。
-
HTTPリソースの
/favicon.ico
を見つけて開きます(または、「新規リソース」ボタンをクリックして、このリソースを追加します)。 -
「リソースURL」を確認または編集して、次のようにします。
/favicon.ico
-
「保護」セクションで、「保護レベル」リストから「除外」を選択して、「適用」をクリックします。
-
ステップ4に進みます。
-
-
独立したWebゲート: リソースWebゲート・アプリケーション・ドメインを開きます。
- ポリシーの構成
- アプリケーション・ドメイン
- ResourceWGDomain
-
認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。
-
このポリシーにDCC認証スキームと、オプションの失敗URLを追加します(指定しない場合、失敗URLはデフォルトのエラー・ページを表示します)(「特定のリソースに対する認証ポリシーの定義」を参照してください)。
- DCC認証スキーム
- 失敗URL (オプション)
-
Chromeブラウザを使用する場合は、ステップ2を実行します。それ以外の場合は、ステップ4に進みます。
-
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を集約フェデレーション・フローに使用する場合は、次のステップを手動で実行します。
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は、トンネリング・プロセスの仕組みを示しています。
次のステップでは、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.2 WebLogic Serverインスタンスの構成
WebLogicコンソールを使用して、SSLおよびクライアント証明書が有効になるようにWebLogic Serverのインスタンスを構成します。
23.6.1.4 ルートCA証明書の追加
SSL対応のWebLogic Serverに使用する証明書ユーティリティのルートCA証明書を追加できます。
(この例では、OpenSSL証明書ユーティリティが使用されています。)ルートCA証明書は、次のWebLogicディレクトリにある.oamkeystore
およびamtruststore
ファイルに追加する必要があります。
$DOMAIN_HOME/base_domain/config/fmwconfig
-
WebLogicの
.oamkeystore
およびamtruststore
ファイルのパスワードを取得します。-
$MIDDLEWARE_HOME/Oracle_IDM1/common/bin/に移動します。
-
wlst.shを実行します。
-
WLSTシェルのconnect()を実行します。
-
WLSTシェルのdomainRuntime()を実行します。
-
WLSTシェルのlistCred(map="OAM_STORE",key="jks")を実行して、パスワードを表示します。
-
-
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認証スキームのコピーを作成して次の値を変更し、新しい認証スキームを作成します。
次の値のみを変更し、その他のパラメータ名はそのままにします。
-
LDAPScheme_DCCと名前を付けます。
-
チャレンジ・リダイレクトURLはhttp://<host>:<port>/ (http://<host>:7779/)です。
-
チャレンジURL: /oamsso-bin/login.pl
-
-
ABC_WG1アプリケーション・ドメインに移動して、次を実行します。
-
「認証ポリシー」に移動します。
-
「認証ポリシー」(保護されたリソース・ポリシー)を選択します。
-
新しく作成された認証スキームLDAPScheme_DCCを選択します。
-
-
ポート7779を使用するOracle HTTP Serverを再起動します。
-
保護されたリソース(http://<host>:7778/index.html)にアクセスします。
認証Webゲート・サーバー(ポート7779)からチャレンジ・ページを取得する必要があります。有効な資格証明を指定すると、ポート7778サーバーのリソースが表示されます。
23.6.3 SSLへのDCC Webゲートの変換
23.6.3.1 サーバー証明書の生成
Oracle Wallet Manager (OWM)を使用して、サーバー証明書を生成できます。
-
OWMを使用して、ウォレットを作成します。
-
OWMを起動します。
$ <webtier>/bin/owm
-
ウォレット」→「新規」を選択し、画面の指示に従って証明書リクエストを作成します。
-
作成したウォレットをアクセス可能な場所に保存し、後で参照できるようにパスを書き留めておきます。
-
「自動ログイン」オプションを選択して、ウォレットを再度保存します。
-
-
OWMを使用し、サーバー・リクエスト・ファイルをserver.csrとして作成してエクスポートします。
-
「操作」→「証明書リクエストのエクスポート」を選択します。
-
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にインポートします。
-
「操作」→「信頼できる証明書のインポート」を選択します。
-
ca.pem(CA証明書)を参照します。
-
CA証明書をインポートしてウォレットを保存します。
-
-
server.pemをユーザー証明書としてインポートします。
-
「操作」→「ユーザー証明書のインポート」を選択します。
-
ステップ3で生成されたserver.pem証明書を参照します。
-
サーバー証明書をインポートしてウォレットを保存します。
-
-
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インスタンスを再起動します。