| Oracle® Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイド 11gリリース2 (11.1.2.1.0) B72797-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity and Access Managementサードパーティ・アプリケーション・サーバー・ガイド 11gリリース2 (11.1.2.1.0) B72797-01 |
|
前 |
次 |
Oracle Adaptive Access Managerは、エンタープライズ向けにWebアクセスのリアルタイム不正検出およびオンライン多要素認証セキュリティを提供するOracle Identity Managementのソリューションです。
この章では、IBM WebSphereでのOracle Adaptive Access Managerの管理と統合について情報を提供し、同プラットフォームのいくつかの機能について詳しく説明します。この章では、特にIBM WebSphereに適用されるトピックのみを扱っています。Oracle WebLogic Serverに適用されるトピックはここでは説明しませんが、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』、および『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』に説明があります。
この章には次の項が含まれます:
Oracle Adaptive Access Managerを構成する前に、依存性を含む必要なすべてのコンポーネントをインストールし、後続の構成タスクに備えて環境を構成しておく必要があります。
表8-1 インストール・タスク
| 手順 | タスク | 情報 |
|---|---|---|
|
1 |
次のソフトウェアを取得します。
|
必須ソフトウェアの取得方法の詳細は「タスク2: 必要なソフトウェア・メディアとダウンロードの取得」を参照してください。 |
|
2 |
リポジトリ作成ユーティリティ(RCU)を使用して、データベース内でOAAMスキーマを作成または更新します。 |
スキーマ作成の詳細は、「タスク3: データベースの特定と必要なデータベース・スキーマのインストール」を参照してください。 |
|
3 |
IBM WebSphereソフトウェアをインストールします。 |
IBM WebSphereソフトウェアのインストールの詳細は、「タスク4: IBM WebSphereソフトウェアのインストール」を参照してください。 |
|
4 |
Oracle Identity and Access Management Suiteをインストールします。 |
IBM WebSphereでのOracle Identity and Access Managementのインストールの詳細は、第2章「IBM WebSphereでのOracle Identity and Access Managementのインストールおよび構成」と『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』を参照してください。 |
|
5 |
新しいIBM WebSphereセルでOracle Fusion Middlewareコンポーネントを構成します。 |
セルとは、管理ドメイン全体を包含する単一の管理ドメイン内にあるノードのグループです。 第2.8.1項「IBM WebSphereでの構成ウィザードの使用方法に関する一般情報」では、構成ウィザードを使用して、単純なIBM WebSphereセルにOracle Fusion Middleware製品を構成する方法について説明します。サーバーおよびクラスタのセルへの追加に関する情報も含めた、Oracle Fusion Middleware構成ウィザードの使用方法の詳細は、『Oracle Fusion Middleware IBM WebSphere Application Server構成ガイド』を参照してください。 |
|
6 |
ポリシー再アソシエーションの変更を実行します。 |
再アソシエーション変更の実行の詳細は、「タスク9: データベース・セキュリティ・ストアの構成」を参照してください。 |
|
7 |
サーバーを起動します。 |
サーバーの起動の詳細は、「サーバーの起動」を参照してください。 |
Oracle Fusion Middlewareソフトウェアが正常に構成された後は、IBM WebSphereのデプロイメント・マネージャ、ノード、およびサーバーを起動できます。IBM WebSphereセルでのサーバーの起動と停止には、次の2つの方法があります。
プロファイル・スクリプトを使用
Oracle Enterprise Manager Fusion Middleware Controlを使用
次の手順は、プロファイル・スクリプトの実行方法と、デプロイメント・マネージャ、ノード、サーバーをセルで起動するために必要な順序を示しています。IBM WebSphereサーバーの起動の詳細は、第2.10項「IBM WebSphereサーバーの起動」を参照してください。
デプロイメント・マネージャを起動するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/deployment_mgr_profile_name/bin/startManager.sh (Windows) WAS_HOME\profiles\deployment_mgr_profile_name\bin\startManager.cmd
たとえば、UNIXオペレーティング・システムでは次のようになります。
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/startManager.sh
WAS_HOMEは、IBM WebSphereがインストールされているAppServerディレクトリへのパスです。
ノードとは、1つのオペレーティング・システム・インストール内で構成および操作管理に対応するアプリケーション・サーバーの管理グループです。ノードを同期化するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/profile_name/bin/syncNode.sh DMGR_HOST DMGR_SOAP_PORT -username admin_user -password admin_password (Windows) WAS_HOME\profiles\profile_name\bin\syncNode.cmd DMGR_HOST DMGR_SOAP_PORT -admin_user username -password admin_password
ノードを起動するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/profile_name/bin/startNode.sh (Windows) WAS_HOME\profiles\profile_name\bin\startNode.cmd
たとえば、UNIXオペレーティング・システムでノードを起動するには、次のように入力します。
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startNode.sh
OracleAdminServerを起動するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/profile_name/bin/startServer.sh OracleAdminServer (Windows) WAS_HOME\profiles\profile_name\bin\startServer.cmd OracleAdminServer
たとえば、UNIXオペレーティング・システムでOracleAdminServerを起動するには、次のように入力します。
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
OracleAdminServer
OracleAdminServerの起動後には、IBM WebSphere Administrative ConsoleまたはOracle Enterprise Manager Fusion Middleware Controlを使用してその他のサーバーを起動できます。詳細は、第3.1項「IBM WebSphereのOracle Fusion Middleware管理ツールのサマリー」を参照してください。
OAAM管理サーバーを起動するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) OAAM_PROFILE/bin/startServer.sh oaam_admin_server1 (Windows) OAAM_PROFILE\bin\startServer.cmd oaam_admin_server1
OAAM管理サーバーのデフォルトのサーバー名は、oaam_admin_server1です。
たとえば、UNIXオペレーティング・システムでOAAM管理サーバーを起動するには、次のように入力します。
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
oaam_admin_server1
OAAM_PROFILEは、OAAM管理サーバーがインストールされているIBM WebSphereプロファイルです。
たとえば、UNIXオペレーティング・システムでは、OAAM_PROFILEは次のようになります。
WAS_HOME/profiles/profile_name
OAAMサーバーを起動するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) OAAM_PROFILE/bin/startServer.sh oaam_server_server1 (Windows) OAAM_PROFILE\bin\startServer.cmd oaam_server_server1
OAAMランタイム・サーバーのデフォルトのサーバー名は、oaam_server_server1です。
OAAM_Profileは、OAAMサーバーがインストールされているIBM WebSphereプロファイルです。
たとえば、UNIXオペレーティング・システムでOAAMランタイム・サーバーを起動するには、次のように入力します。
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/startServer.sh
oaam_server_server1
たとえば、UNIXオペレーティング・システムでは、OAAM_PROFILEは次のようになります。
WAS_HOME/profiles/profile_name
プロファイル・スクリプトまたはOracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Fusion Middlewareに構成したセル内でサーバーを停止できます。
Fusion Middleware ControlからIBM WebSphereサーバーを停止することもできます。
たとえば、Fusion Middleware Controlからサーバーを停止する手順は次のとおりです。
Fusion Middleware Controlにログインします。
Fusion Middleware Controlのポート番号とURLを検索するには、第3.1.2.2項「Fusion Middleware Controlのポート番号とURLの検索」を参照してください。
サーバーのホームページに移動します。
詳細は、第3.1.2.5項「Fusion Middleware ControlからのIBM WebSphereサーバーの表示」を参照してください。
「WebSphere Application Server」メニューから、「コントロール」→「停止」の順に選択します。
Fusion Middleware Controlに、確認のダイアログ・ボックスが表示されます。
「停止」をクリックします。
プロファイル・スクリプトを使用してIBM WebSphereサーバーを停止することもできます。
IBM WebSphereサーバーを停止するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) OAAM_PROFILE/bin/stopServer.sh server_name -username username -password password (Windows) OAAM_PROFILE\bin\stopServer.cmd server_name -username username -password password
OracleAdminServerを停止するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/profile_name/bin/stopServer.sh OracleAdminServer (Windows) WAS_HOME\profiles\profile_name\bin\stopServer.cmd OracleAdminServer
たとえば、UNIXオペレーティング・システムでは次のようになります。
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/stopServer.sh
OracleAdminServer
ノードを停止するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/profile_name/bin/stopNode.sh -username admin_user -password admin_password (Windows) WAS_HOME\profiles\profile_name\bin\stopNode.cmd -username admin_user -password admin_password
たとえば、UNIXオペレーティング・システムでは次のようになります。
/opt/IBM/WebSphere/AppServer/profiles/Custom01/bin/stopNode.sh -username admin_user -password admin_password
デプロイメント・マネージャを停止するには、IBM WebSphereのホームで次のディレクトリに移動して、次のコマンドを入力します。
(UNIX) WAS_HOME/profiles/deployment_mgr_profile_name/bin/stopManager.sh -username admin_user -password admin_password (Windows) WAS_HOME\profiles\deployment_mgr_profile_name\bin\stopManager.cmd -username admin_user -password admin_password
たとえば、UNIXオペレーティング・システムでは次のようになります。
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/stopManager.sh -username admin_user -password admin_password
デフォルトでは、OAAM管理コンソールへのログイン権限を持つユーザーはOAAMに用意されていません。ユーザーを作成して、必要なグループをそのユーザーに付与する必要があります。IBM WebSphereセル用に構成されたLDAPディレクトリ内にユーザーとグループを定義する必要があります。IBM WebSphereでのユーザーおよびグループの作成の詳細は、IBM WebSphereのドキュメントを参照してください。
表8-2に、Oracle Adaptive Access Managerに同梱されているデフォルトのロールをリストします。
表8-2 OAAMのロール
| ロール名 | ロール | 説明 |
|---|---|---|
|
OAAMCSRGroup |
CSRGroupロール |
サポート担当者 |
|
OAAMCSRManagerGroup |
CSRManagerGroupロール |
サポート担当者 |
|
OAAMInvestigatorGroup |
Investigatorロール |
調査担当者 |
|
OAAMInvestigationManagerGroup |
InvestigationManagerロール |
調査担当者 |
|
OAAMRuleAdministratorGroup |
RuleAdministratorsGroupロール |
セキュリティ管理者 |
|
OAAMEnvAdminGroup |
EnvAdminGroupロール |
システム管理者 |
|
OAAMSOAPServicesGroup |
SOAPServicesGroupロール |
ユーザーに、URL |
OAAMコマンドライン・インタフェース(CLI)スクリプトでは、OAAM管理コンソールを使用しないで様々なタスクを実行できます。
CLI環境の設定には、次のタスクが含まれます。
CLI作業ディレクトリの設定
資格証明ストア・フレームワーク(CSF)の構成の設定
OAAMデータベース資格証明の設定
CLIディレクトリを作業ディレクトリにコピーします。
cp -r ORACLE_MW_HOME/IDM_HOME/oaam/cli /home/user/IBM/oaam.cli
|
注意: Oracle Identity and Access Managementスイートのインストール後に、Oracle Identity and Access ManagementのOracleホーム・ディレクトリ( |
JavaホームおよびMiddlewareホームの環境を設定するには、次の手順に従います。
IBM WebSphere (WAS_HOME/java)内のJDKにJAVA_HOMEを設定します。
set JAVA_HOME=DISK/IBM/WebSphere/Application-Server/java
ORACLE_MW_HOMEをMiddlewareディレクトリ(Oracle_Commonディレクトリへの完全なパス)に設定します。
資格証明ストアは、ユーザー名とパスワードの組合せ、チケットまたは公開鍵証明書を保持できるリポジトリです。Oracle Platform Security Servicesは資格証明ストア・フレームワーク(CSF)を備えています。これは、アプリケーションで資格証明を安全に作成、読取り、更新および管理する際に使用できる一連のAPIです。OAAMではCSF APIを使用して資格証明にアクセスします。資格証明はIBM WebSphereサーバー・ドメインのCSFに格納され、Oracle Enterprise Manager Fusion Middleware Controlを使用して管理されます。
CSFに格納されているOAAM暗号化キーにアクセスするには、次のいずれかのメカニズムを選択します。
Mbeanを含まないCSF
Mbeanを含むCSF
このメカニズムを使用するには、cliディレクトリをコピーした作業ディレクトリに移動し、テキスト・エディタでファイルconf/bharosa_properties/oaam.cli.propertiesを開いて次のプロパティを設定します。
| プロパティ名 | プロパティ値に関する注意事項 |
|---|---|
|
oaam.csf.useMBeans |
|
|
oaam.jps.config.filepath |
WAS_HOME/profiles//Dmgr01/config/cells/slc01hvgCell01/fmwconfig/jps-config-jse.xml |
|
oaam.db.url |
OAAMデータベースの有効なJDBC URLを指定します。 |
|
oaam.db.additional.properties.file |
追加のOracle TopLinkプロパティがない場合は、このフィールドを空白のままにします。 それ以外の場合は、追加のOracle TopLinkプロパティを含むプロパティ・ファイルの名前を指定します。ファイルが |
|
oaam.db.driver |
OAAMスキーマが非Oracleデータベースにある場合のみ、値を変更します。 |
|
oaam.db.min.read-connections |
必要な場合を除き、この値は変更しないでください。 |
|
oaam.db.max.read-connections |
必要な場合を除き、この値は変更しないでください。 |
|
oaam.db.min.write-connections |
必要な場合を除き、この値は変更しないでください。 |
|
oaam.db.max.write-connections |
必要な場合を除き、この値は変更しないでください。 |
MBeanを含むCSFを使用してOAAMデータベースの詳細を構成するには、cliディレクトリをコピーした作業ディレクトリに移動し、テキスト・エディタでファイルconf/bharosa_properties/oaam_cli.propertiesを開いて次のプロパティを設定します。
| プロパティ名 | プロパティ値に関する注意事項 |
|---|---|
|
oaam.csf.useMBeans |
|
|
oaam.adminserver.hostname |
IBM WebSphere管理サーバーが実行しているホスト名。 |
|
oaam.adminserver.port |
IBM WebSphere管理サーバーのデプロイメント・マネージャの IBM WebSphere管理コンソールにログインします。 「System Administration」→「Deployment Manager」→「Configuration」→「Additional Properties」→「Ports」→「ORB_LISTENER_ADDRESS」の順に移動します。 |
|
oaam.was.client.sasPropFile |
IBM WebSphereのリモートJMXクライアントに必要な /home/user/IBM/oaam.cli/sample.sas.client.properties |
|
oaam.db.url |
OAAMデータベースの有効なJDBC URLを指定します。 |
|
oaam.adminserver.type |
|
|
oaam.db.additional.properties.file |
追加のOracle TopLinkプロパティがない場合は、このフィールドを空白のままにします。 それ以外の場合は、追加のOracle TopLinkプロパティを含むプロパティ・ファイルの名前を指定します。このファイルが |
|
oaam.db.driver |
OAAMスキーマが非Oracleデータベースにある場合のみ、この値を変更します。 |
|
oaam.db.min.read-connections |
必要な場合を除き、この値は変更しないでください。 |
|
oaam.db.max.read-connections |
必要な場合を除き、この値は変更しないでください。 |
|
oaam.db.min.write-connections |
必要な場合を除き、この値は変更しないでください。 |
|
oaam.db.max.write-connections |
必要な場合を除き、この値は変更しないでください。 |
OAAM CLIでは、2つの対称鍵(管理サーバーがはじめて起動されると自動的に生成されます)と、データベース資格証明キー(OAAM DBスキーマおよびパスワード)を取得する必要があります。たとえば、CSFからデータベース・スキーマに接続するためのDEV_OAAM/password)。
次のディレクトリに進みます。
CLI_DIR/conf/bharosa_properties
CLI_DIRをCLIがインストールされているディレクトリに置き換えます。
第8.1.4.3項「資格証明ストア・フレームワーク(CSF)の構成の設定」に説明するように、oaam_cli.propertiesをCSF用に編集します。
oaam.uio.oam.hostプロパティをlocalhostに設定します。
setupOAMTapIntegration.shスクリプトを実行してTAP統合用に設定します。
sh setupOAMTapIntegration.sh conf/bharosa_properties/oaam_cli.properties
プロンプトが表示されたら、OAAMデータベースのユーザー名とパスワードを入力して、その他のプロパティに対して[Enter]キーを押します。
このスクリプトにより、資格証明がCSFに追加されます。
|
注意: スクリプトの実行終了時に表示される失敗メッセージは無視してください。 |
資格証明がCSFに追加されたかどうかを検証するには、次の手順を実行します。
管理者アクセス権でFusion Middleware Controlにログインします。
Fusion Middleware Controlのポート番号とURLを検索するには、第3.1.2.2項「Fusion Middleware Controlのポート番号とURLの検索」を参照してください。
ナビゲータで、「Cell_WebSphere」を右クリックして、「Security」→「Credentials」の順に選択します。
oaamというマップを開いて、3つのキーが存在するかどうか確認します。
資格証明ストアの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
設定が終了すると、CLI作業ディレクトリからCLIコマンドを実行できるようになります。このコマンドは、Oracle WebLogicデプロイメントのものと同じです。
コマンドの実行例を次に示します。
CLIエクスポート・コマンドをCLI_DIRから実行します。
sh runImportExport.sh -action export -module properties
Oracle WebLogicまたはIBM WebSphereを選択するためのプロンプトが表示されます。
IBM WebSphereに対して2を選択します。
WAS_HOMEに対する入力が求められます。
WAS_HOMEを設定します。
例: /opt/IBM/WebSphere/AppServer
$IDM_HOMEが設定されていない場合は、ORACLE_HOMEディレクトリに対する入力が求められます。Oracle Identity and Access Management Suiteのインストール時に指定したものと同じORACLE HOMEディレクトリを指定します。たとえば、Oracle_IDM1と指定します。
IBM WebSphere上のOAAMに対して、データベース監査ストアを使用して監査を設定し、有効化します。この項で手順を示します。
監査レコードの永続的ストアとしてデータベースに切り替えるには、最初にリポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・ストアを作成する必要があります。
この項では、監査スキーマの作成方法を説明します。データベース・スキーマの作成後は、次のことが可能になります。
このスキーマを指し示すデータソースを作成します。
ドメイン構成を更新して、監査レコード用に監査データ・ストアを切り替えます。
|
注意: この説明では、RCUおよびデータベースが環境にインストール済であることを前提としています。RCUの使用方法の詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。 |
始める前に
作業を開始する前に、使用するデータベースの詳細情報を収集し、DBA資格証明を入手してください。DEV_IAUまたは対応するユーザーを使用してデータベースにログインできることが必要です。
データベース・スキーマの構成
監査データ・ストア用のスキーマを構成するには、次の手順に従います。
RCU_HOME/binに移動して、RCUユーティリティを実行します。
開始画面で「作成」を選択します。「次へ」をクリックします。
データベースの詳細情報を入力して、「次へ」をクリックします。
新しい接頭辞を作成するオプションを選択します。
また、スキーマのリストから「監査サービス」を選択します。
「次へ」をクリックして、表領域の作成を承認します。
スキーマの作成中にエラーが発生していないか確認します。
次のコマンドを入力して、デプロイメント・マネージャを起動します。
(UNIX) WAS_HOME/profiles/deployment_mgr_profile_name/bin/startManager.sh (Windows) WAS_HOME\profiles\deployment_mgr_profile_name\bin\startManager.cmd
IBM WebSphere管理コンソールにログインします。
データ・ソースを構成する際、まずJ2C認証データ・エントリを作成する必要があります。データベースへのアクセスに必要なユーザーIDとパスワードは、J2C認証データ・エントリで指定されます。
「Security」→「Global Security」→「Java Authentication and Authorization Service」の順にクリックして、「J2C authentication data」を選択します。
「New」をクリックし、IAUスキーマのユーザー名とパスワードを使用して認証データを作成します。
例: DEV_IAU/password。
J2C認証別名には任意の有効な文字列を入力できます。
「OK」をクリックします。
「Servers」→「Server types」→「WebSphere application servers」の順に選択して、すべてのアプリケーション・サーバーを停止します。
ノードを停止します。
例:
WAS_HOME/profiles/Custom01/bin/stopNode.sh
ノードを同期化します。
例:
WAS_HOME/profiles/Custom01/bin/syncNode.sh host soap-port
デプロイメント・マネージャを停止します。
例:
WAS_HOME/profiles/Dmgr01/bin/stopManager.sh
デプロイメント・マネージャを起動します。
例:
WAS_HOME/profiles/Dmgr01/bin/startManager.sh
ノードを起動します。
例:
WAS_HOME/profiles/Custom01/bin/startNode.sh
第8.2.1項「RCUによる監査スキーマの作成」で説明したように、データベースに監査レコードを格納するデータベース・スキーマを作成した後、そのスキーマを指すIBM WebSphereサーバーの監査データソースを設定する必要があります。これを行うには:
IBM WebSphere管理コンソールを使用して、OAAMデータベース用にIBM WebSphereデータソースを作成します。
IBM WebSphere管理コンソールにログインします。
http://host:port/ibm/console
IBM WebSphere管理コンソールの左パネルで、「Resource」セクションの下で「JDBC」を開いて「Datasource」をクリックします。
「Cell」スコープを選択して、「New」をクリックします。
IBM WebSphere管理コンソールで表示するデータソースの名前を入力し、データソースのバインド先であるJNDI名を指定するように求められます。
OracleAdminServer、oaam_admin1、およびoaam_server1のスコープ別にjdbc/AuditDBというJNDIを使用してデータ・ソースを作成します。
oaam_admin1の監査データ・ソースの場合は、データ・プロバイダとしてOAAM_ADMIN_DBを選択し、「Component-managed authentication alias」では、第8.2.3項「J2C認証データの作成」で作成したJ2C認証IDを選択します。
oaam_server1の監査データ・ソースの場合は、データ・プロバイダとしてOAAM_SERVER_DBを選択し、「Component-managed authentication alias」では、第8.2.3項「J2C認証データの作成」で作成したJ2C認証IDを選択します。
OracleAdminServerの監査データ・ソースの場合は、データ・プロバイダとしてmds-oaamを選択し、「Component-managed authentication alias」では、第8.2.3項「J2C認証データの作成」で作成したJ2C認証IDを選択します。
ノードを同期化した後で、新しく作成されたデータ・ソースの接続をテストします。第8.1.1.2項「ノードの同期化」の手順に従います。
データ・ソースを選択し、「接続のテスト」ボタンをクリックして、各接続をテストします。新しく作成した3つのデータ・ソースのテスト接続がすべて成功していることを確認します。
監査リポジトリを設定するには、次の手順に従います。
OAAM Oracleホームのcommon/binディレクトリからOracle Fusion Middlewareのwsadminコマンドライン・シェルを起動します。
このコマンド構文を使用します。
(UNIX) IDM_HOME/common/bin/wsadmin.sh -profileName profilename -connType SOAP -user admin_user -password admin_password (Windows) IDM_HOME\common\bin\wsadmin.cmd -profileName profilename -connType SOAP -user admin_user -password admin_password
例:
sh $IDM_HOME/common/bin/wsadmin.sh -profileName Dmgr01 -connType SOAP -user wasadmin -password welcome1
wsadminコマンドを実行して、監査リポジトリをデータベースに設定します。
wsadmin>Audit.setAuditRepository(switchToDB='true',dataSourceName='jdbc/AuditDB',interval='14')
成功した場合は、次の情報が表示されます。
Audit Repository Information updated Server has to be restarted
ノードとマネージャを停止してから再起動します。「Servers」→「Server types」→「WebSphere application servers」の順に選択して、すべてのアプリケーション・サーバーを起動します。
IBM WebSphereセルの一環としてインストールし構成したOracle Fusion Middleware製品は、Fusion Middleware Controlから管理できます。
「監査ポリシー設定」ページでは、監査イベントを管理します。各コンポーネントとそのイベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。
Fusion Middleware Controlにログインします。
Fusion Middleware Controlのポート番号とURLを検索するには、第3.1.2.2項「Fusion Middleware Controlのポート番号とURLの検索」を参照してください。
Fusion Middleware Controlの「ターゲット・ナビゲーション・ペイン」で、「WebSphereセル」→「Cell_WebSphere」の順に移動します。
「Cell_WebSphere」を右クリックして、「セキュリティ」→「監査ポリシー設定」の順に移動します。「監査ポリシー設定」ページが表示されます。
事前構成済監査レベルのドロップダウン・リストを選択できます。2つの事前定義済レベル(「低」、「中」)では、すべてのコンポーネントの監査イベントのサブセットを自動的に選択します。ほとんどの場合は、事前定義済のレベルで十分です。
なし: 監査対象のイベントは選択されません。
低: 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。
中: 「低」のイベント・セットのスーパーセットです。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。
カスタム: このレベルではポリシーを微調整できます。次の表は、ドメイン内で実行中のアプリケーションを示しています。
表は、次の列から構成されています。
名前: ドメイン内のコンポーネントとアプリケーションが表示されます。
監査の有効化: 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。
フィルタ: イベント・タイプで有効なフィルタが表示されます。
監査イベントを有効化して、「適用」をクリックします。
監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより、すべてのイベントを選択するか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択できます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用して、監査方法をより詳細に制御できます。
フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。
アイコンをクリックし、「フィルタの編集」ダイアログを表示します。
「障害のみ選択」ボタンをクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。
インポート/エクスポート: これらのボタンにより、ポリシー構成を保存し、再使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。
必要に応じ、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。
ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。
すべての関連アプリケーション・サーバーの停止、ノードの停止、ノードの同期化、マネージャの停止、マネージャの起動、ノードの起動、アプリケーション・サーバー/アプリケーションの起動。
この項では、OAAMをテスト環境から本番環境に移行する方法について説明します。テスト環境内でポリシーおよびルールの開発とテストを行い、最終的には新しいポリシーとルールを、また、必要に応じてテスト・データを本番環境にロール・アウトできます。
OAAMコンポーネントを移行しない場合、移行元の環境で行ったカスタマイズや構成変更は、移行先の環境にすべて再適用する必要がありますが、コンポーネントを移行することにより、このような作業が最小化されます。テスト環境では、OAAMのインストール、構成、カスタマイズおよび検証を行うことができます。システムが安定し、必要に応じて機能するようになったら、本番環境を作成します。このとき、テスト環境に取り込んだすべての変更内容を再実行するかわりに、コンポーネントとその構成のコピーをテスト環境から移行することで本番環境を作成できます。既存の本番環境がある場合は、カスタマイズなど、テスト環境のすべての変更内容を本番環境に移行できます。
Oracle Adaptive Access Managerを新しい本番環境に移行するには、次のガイドラインに従います。デプロイメントに関連するアイテムに関して、本番環境を手動で更新します。
スナップショットとは、現在のシステム構成のバックアップのことです。OAAM CLIを使用し、テスト環境からOAAMスナップショットをエクスポートします。スナップショットのエクスポートの例を次に示します。
runImportExport.sh -action export -module snapshot -snapshotname "name of snapshot" -description "snapshot description"
runImportExport.sh -action export -module snapshot -snapshotname "OAAM Snapshot" -description "OAAM snapshot description"
オプション-snapshotname , -descriptionはオプションです。snapshotnameが指定されている場合、エクスポートされたZIPファイル名はvalue passed for -snapshotname.zipとなります。snapshotnameが指定されていない場合、CLIでは、snapshot_unique_valueなどの名前を持つ一意のファイル名が作成されます。
エクスポートされるZIPファイルには、次の内容で構成されたsnapshot.propertiesファイルも1つ含まれます。
| プロパティ | 説明 |
|---|---|
|
serverIP |
CLIが実行されるサーバーのIPです。 |
|
user |
オペレーティング・システムのユーザー名 |
|
name |
|
|
description |
|
|
serverName |
CLIが実行されたホスト名です。 |
いくつかの構成を本番環境に移行していて、スナップショット全体をエクスポートする必要がない場合は、OAAM管理コンソールを使用して個別のコンポーネントの構成をZIPファイルにエクスポートします。エクスポートの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』で特定の章を参照してください。
表8-3に、個別にエクスポートできるOAAMの構成をリストします。
表8-3 個別の構成のエクスポート
| 構成 | 情報 |
|---|---|
|
ポリシー |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のポリシーのエクスポートに関する項を参照してください。 |
|
ルール条件 |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』の条件のエクスポートに関する項を参照してください。 |
|
パターン |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のパターンのエクスポートに関する項を参照してください。 |
|
構成可能なアクション |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のアクション・テンプレートのエクスポートに関する項を参照してください。 |
|
トランザクション定義 |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のトランザクション定義のエクスポートに関する項を参照してください。 |
|
エンティティ |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のエンティティのエクスポートに関する項を参照してください。 |
|
KBAの質問 |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』の質問のエクスポートに関する項を参照してください。 |
|
KBAの検証 |
『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のエンティティのエクスポートに関する項を参照してください。 |
スナップショットを本番システムにインポートする前に、本番システムのシステム構成全体が置き換えられることを認識しておく必要があります。インポートが失敗した場合、または予想していなかったその他の問題が生じた場合に現在の構成が失われないようにするために、インポート前に現在の本番環境のスナップショットを作成しておく必要があります。スナップショットをインポートした後でインポートを元に戻すことはできませんが、バックアップがあれば、インポートが失敗した場合でも元の構成をただちにシステムにリストアすることができます。
スナップショットを作成すると、機能領域のすべての構成(アクティブな構成と無効な構成の両方)が選択されます。たとえば、ポリシー・セット内に10個のポリシーがあり、そのうち5個がアクティブで、5個が無効になっている場合、スナップショットを作成すると、すべてのポリシーとその構成およびステータス情報が含められます。
バックアップおよびリストア時には、アイテムのステータスは保存されます。たとえば、無効なアイテムは、バックアップおよびリストア時も無効なままです。
個別のアイテムを選択してスナップショットに含めたり、選択的なリストアを実行することはできません。特定の構成のみをスナップショットに含める場合は、そのモジュールからそれらの構成をエクスポートして再びインポートした後、スナップショットを作成できます。
スナップショットの場合、メタデータは次のアイテムとともに格納されます。
| アーティファクト | コメント | 追加の注意事項 |
|---|---|---|
|
ポリシー・セット |
ポリシー・セットのオーバーライド |
追加の注意事項はありません。 |
|
ポリシー |
すべてのポリシー |
トリガー組合せを含みます。 |
|
ルール・インスタンス |
すべてのルール・インスタンス |
追加の注意事項はありません。 |
|
条件 |
すべてのルール条件 |
追加の注意事項はありません。 |
|
グループ |
リンクされているかどうか、すべてのグループのグループ定義 |
アラートおよびアクションのグループ・メンバーのみがエクスポートされます。 |
|
パターン |
すべてのパターン |
追加の注意事項はありません。 |
|
トランザクション定義 |
すべてのトランザクション定義 |
追加の注意事項はありません。 |
|
エンティティ |
リンクされているかどうか、すべてのエンティティ |
追加の注意事項はありません。 |
|
プロパティ |
データベース内のみ |
追加の注意事項はありません。 |
|
列挙 |
データベース内のみ |
追加の注意事項はありません。 |
|
構成可能なアクション |
追加の注意事項はありません。 |
|
|
チャレンジ質問 |
検証、カテゴリおよび構成を含む(回答ロジックなど) |
追加の注意事項はありません。 |
構成データをデータベースまたはファイルにバックアップします。ファイルの場合は、CLIまたはUniversal Risk Snapshot機能を使用してエクスポートを実行します。
スナップショットにはグループのメンバーは含められません(アクション・グループおよびアラート・グループを除く)。ただし、グループそのものはスナップショットに含められます。グループ・メンバーをバックアップするには、スナップショットのエクスポートとは別にグループのエクスポートを実行する必要があります。これらのグループ・メンバーは、必要に応じて「グループ」ユーザー・インタフェースを使用してインポートする必要があります。
グループをエクスポートするには、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のグループのエクスポートに関する項を参照してください。
次に、スナップショットのインポートの手順を示します。
システムで使用するスナップショットをユニバーサル・リスク・スナップショット機能を使用してインポートするには、次の手順に従います。
ナビゲーション・ツリーで、「環境」にある「システム・スナップショット」を開きます。
システム・スナップショット検索ページが表示されます。
「ファイルからロード」ボタンをクリックします。
「スナップショットのロードおよびリストア」ダイアログが表示されます。スナップショットをインポートすると現在のシステムの構成内容が上書きされるため、ここで現在のシステムをバックアップしておくこともできます。
現在のシステムのバックアップを保持しておくには、「現在のシステムを今すぐバックアップ」ボックスを選択し、バックアップの名前とノートを入力したら「続行」をクリックします。
「スナップショットのロードおよびリストア」ダイアログが表示され、現在のシステムが正常にデータベースに格納されたことを示すメッセージが示されたら、「OK」をクリックします。
続いて、「スナップショットのロードおよびリストア」ページが表示されたら、サーバーにロードするスナップショットを選択し、基本的な認証フローを実行します。
現在の構成のバックアップが確実に必要ない場合や、空のシステムにスナップショットをインポートする場合は、ダイアログを空白のままにして「続行」をクリックします。
システムのバックアップを選択しなかったために、新しいスナップショットをロードするとメタデータの詳細が上書きされる可能性があることを示す警告が表示されます。バックアップを取得する場合は、「戻る」ボタンをクリックして前のページに戻り、バックアップの詳細を指定します。インポートを進める場合は、「続行」をクリックします。
「スナップショットのロードおよびリストア」ページが表示されたら、サーバーにロードするスナップショットを選択し、基本的な認証フローを実行します。
これで、スナップショットをロードできるようになりました。ダイアログの「参照」ボタンをクリックして、ロードするスナップショットのファイル名を入力します。画面が表示されたら、スナップショット・ファイルが配置されているディレクトリに移動します。「オープン」をクリックします。続いて、「ロード」ボタンをクリックして、スナップショットをシステムにロードします。
即時利用可能なスナップショットを初めてロードする場合、スナップショット・ファイルoaam_base_snapshot.zipはOracle_IDM1/oaam/initディレクトリにあります。このディレクトリにはOAAMに付属している基本コンテンツが配置されています。
「OK」をクリックします。
スナップショットがロードされると、スナップショットのサマリーが表示されます。
「プレビュー」タブでは、次のことを実行できます。
スナップショット内の条件、ルール、ポリシーなどを表示できます。
オブジェクトに実行されるアクションを表示できます。たとえば、構成可能なアクションを含むスナップショットをロードする際に、構成可能なアクションがシステムにない場合は、その構成可能なアクションは無効になります。
更新分、変更分、または追加分のみなど、オブジェクトをフィルタして確認できます。
スナップショットをロードする際に、システム内の構成を無効にしてしまう可能性や既存のメタデータを上書きしてしまう可能性があるため、通常は前述したシステム内の変更はすべて確認する必要があります。
「更新」ボタンを使用すると、スナップショットを更新または別のスナップショットに変更し、既存のシステム・スナップショットと比べた場合の変更点を表示できます。
しかし、スナップショット内のアイテムはまだ有効ではありません。「リストア」ボタンをクリックするまでは、スナップショット内のアイテムは適用されません。
スナップショットを適用するには、「リストア」をクリックします。
スナップショットを適用したら、それが「システム・スナップショット」ページに表示されていることを確認します。検索を実行して、データベースにロードされているすべてのスナップショットを表示します。任意のスナップショットをクリックして表示し、「リストア」をクリックして変更を適用します。この機能を使用すると、システムを定期的にバックアップできます。バックアップはデータベースのメモリーまたはファイル、あるいはその両方に保存されます。
スナップショットのインポートではアクション・グループおよびアラート・グループがコピーされるだけなので、グループ・メンバーを本番環境にインポートする必要があります。グループを本番環境にインポートするには、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のグループのインポートに関する項を参照してください。
構成可能アクションがスナップショットに含まれている場合は、スナップショットがシステムに復元されたときに構成可能アクションが壊れないように、スナップショットの作成後に、指定されたディレクトリにJavaクラスをコピーする必要があります。
共有ライブラリは、複数のアプリケーションで使用されるファイルです。デプロイされたアプリケーションは共有ライブラリ・ファイルを使用するため、ライブラリ・ファイル用に共有ライブラリを定義して、ライブラリを特定のアプリケーションと関連付ける必要があります。
次のファイルをコピーし、この項に示す手順に基づいてカスタム共有ライブラリを構成します。
OAAMサーバーでカスタマイズされたすべてのアイテム(ヘッダー、フッター、Cascading style sheets (CSS)、JavaScriptなど)
カスタムjarに入っている仮想認証デバイス(VAD)イメージ
プロパティ・ファイル、リソース・バンドル、およびエンドユーザーJSP画面
複数のアプリケーションでライブラリ・ファイルを使用できるようにするには、次の手順に従って共有ライブラリを作成します。
IBM WebSphere管理コンソールにログインします。
コンソールのナビゲーション・ツリーで、「Environment」を開き、「Shared libraries」を選択します。
「共有ライブラリ」ページで、「Show scope selection drop-down list with the all scopes option」を選択し、共有ライブラリ・スコープを選択します。
表の上の「プリファレンス」の下で、「新規」ボタンをクリックして、ステップ3で選択したスコープに新しい共有ライブラリを作成します。
共有ライブラリの設定ページの「名前」フィールドで、共有ライブラリの名前を指定します。
「Classpath」テキスト・ボックスで、次のディレクトリに存在するすべてのJARファイルの絶対パスを指定します。
MW_HOME/Oracle_IDM1/oaam/oaam_libs/directory_name.
これらは、製品で共有ライブラリのクラスおよびリソースの検索に使用するパスです。
|
注意: エントリごとに新規行を使用する必要があり、";"や":"のようなパス・セパレータを使用しないでください。 |
「OK」をクリックして、「Save」をクリックします。
アプリケーションに共有ライブラリ参照を追加するには:
IBM WebSphere管理コンソールにログインします。
コンソールのナビゲーション・ツリーで、「Applications」を開き、「Application Types」を選択して、「WebSphere enterprise applications」をクリックし、アプリケーションのリストを開きます。
「Enterprise Applications」ページで、共有ライブラリを参照する必要のあるアプリケーションをクリックします。
「Configurations」の下で、「Shared library references」をクリックします。
「Shared Library Mapping for Modules」セクションで、アプリケーションの横のチェック・ボックスを選択して、表の上にある「Reference Shared Libraries」ボタンをクリックします。
「Available」リストから共有ライブラリを選択し、それを「Selected」リストに移動します。
「OK」をクリックして、「Save」をクリックします。
ステップ2から7を繰り返します。
共有ライブラリを参照しているすべてのアプリケーション・サーバーを停止します。
ノードを停止します。
ノードを同期化します。
デプロイメント・マネージャを停止します。
デプロイメント・マネージャを起動します。
ノードを起動します。
共有ライブラリを参照しているアプリケーション・サーバー/アプリケーションを起動します。
OAAM管理コンソールを使用して、KBAロジック、OTPロジックおよびポリシー・セットのオーバーライドを手動で再作成します。これらの再作成についての詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。
次の手順を実行して、移行が正常に行われたかどうかを検証します。
OAAM管理コンソールにログインします。
http://oaam_managed_server_host:oaam_admin_managed_server_port/oaam_admin
「ポリシー」モジュールに移動し、テスト環境のルールおよびグループが本番環境に存在することを確認します。
KBAモジュールに移動し、テスト環境のチャレンジ質問が本番環境に存在することを確認します。
Oracle Adaptive Access Manager用に構成されたWebアプリケーションをテストします。ユーザーは、登録およびチャレンジ・フローにリダイレクトされます。
Juniper Networks Secure Access (SA)とOracle Adaptive Access Managerとの統合により、企業は、厳密なマルチファクタ認証と高度なリアルタイム不正行為防止機能を備えたリモート・アクセス制御ソリューションを実装して、企業のアプリケーションにセキュアにアクセスすることができます。
Oracle Adaptive Access ManagerとJuniper Networks Secure Access (SA)を統合してOracle Adaptive Access Managerの認証フローとパスワードを忘れた場合のフローを使用するには、この項の手順を参照してください。
表8-4に、Oracle Adaptive Access ManagerとJuniper SAとの統合に対応する高レベルのタスクの概要を示します。
表8-4 JuniperとOAAMの統合フロー
| 手順 | タスク | 情報 |
|---|---|---|
|
1 |
前提条件を確認します。 |
詳細は、「IBM WebSphere上のOAAMに対するJuniper統合の前提条件」を参照してください。 |
|
2 |
認証プロバイダを構成します。 |
詳細は、「認証プロバイダの構成」を参照してください。 |
|
3 |
Oracle Platform Security Servicesを認証用に構成します。 |
詳細は、「Oracle Platform Security Services (OPSS)の統合用の構成」を参照してください。 |
|
4 |
ノードを同期化し、サーバーを再起動します。
|
詳細は、「ノードの同期化とサーバーの再起動」を参照してください。 |
|
5 |
サーバー・プロパティをインポートします。 |
詳細は、「OAAM管理コンソールを使用したSAML構成関連サーバー・プロパティのインポート」を参照してください。 |
|
6 |
証明書またはトラストを設定します。 |
詳細は、「アサーションの署名に対する証明書の設定」を参照してください。 |
|
7 |
統合プロパティを変更します。 |
詳細は、「OAAM管理コンソールを使用した統合プロパティの変更」を参照してください。 |
|
8 |
Juniper Networks Secure Access (SA)を構成します。 |
詳細は、「Juniper Networks Secure Access (SA)の構成」を参照してください。 |
この統合手順の場合は、次のソフトウェアを取得する必要があります。
IBM WebSphere 7.0および、IBM WebSphereソフトウェアに必要なすべての修正パック
IBM WebSphereソフトウェアの取得とインストールについては、IBM WebSphereドキュメントを参照してください。詳細は、第1.4項「IBM WebSphereでのOracle Identity and Access Management製品の使用に関するドキュメント・リソース」を参照してください。
Juniperドキュメントに従って構成されたJuniper
Juniper SA構成の詳細は、次のサイトで入手可能な『Juniper Networks Secure Access管理ガイド』を参照してください。
『Oracle Fusion Middleware Oracle Identity and Access Managementインストレーション・ガイド』および第2章「IBM WebSphereでのOracle Identity and Access Managementのインストールおよび構成」に従って構成されたOracle Adaptive Access Manager。
IBM WebSphereアプリケーション・サーバーでは、ユーザー・レジストリまたはユーザー・リポジトリはユーザーを認証し、ユーザーとグループに関する情報を取得して、認証および認可を含むセキュリティ関連の機能を実行します。ユーザーおよびグループに関する情報は、レジストリまたはリポジトリの内部に常駐しています。IBM WebSphereアプリケーション・サーバーは、ユーザー・レジストリまたはユーザー・リポジトリを使用してアクセス制御を決定します。
IBM WebSphereのユーザー・レジストリから切り替えてLDAPユーザー・レジストリを使用する場合の詳細は、IBM WebSphereドキュメントを参照してください。
LDAPを指し示すようにIBM WebSphereアプリケーション・サーバーにデフォルトのアイデンティティ・ストアを構成するには、次のように処理します。
LDAPの詳細を使用してLDAPプロパティ・ファイルを準備します。
必須プロパティの設定の詳細は、第9.1項「IBM WebSphereアイデンティティ・ストア」を参照してください。
次のディレクトリに進みます。
MW_HOME/oracle_common/common/bin
JAVA_HOMEを(IBM WebSphereにバンドルされている)IBM JDKに設定します。
たとえば、次のようになります(cshの場合)。
setenv JAVA_HOME /opt/IBM/WebSphere/AppServer/java
WSADMINコマンドを実行して、アイデンティティ・ストアをIBM WebSphereに構成します。
wsadmin.shコマンドを実行して、WSADMINシェルを起動します。
./wsadmin.sh -port SOAP_PORT -user wasadmin_user -password password -conntype SOAP
例:
./wsadmin.sh -port port -user wasadmin -password pass -conntype SOAP
WASセルの設定時に指定したものと同じ資格証明を使用する必要があります。
wsadminプロンプトから、次のWSADMINコマンドを実行します。
Opss.configureIdentityStore(propsFileLoc="/tmp/oud.properties") - oud.properties
propsFileLocにより、LDAPアイデンティティ・ストアのプロパティ設定が含まれているファイルの場所が指定されます。このコマンドにより、プロパティ・ファイル内の仕様が含まれるように構成ファイルjps-config.xmlが変更されます。
OPSS.configIdentityStore()コマンドにより、IBM WebSphereアプリケーション・サーバーにあるデフォルトのアイデンティティ・ストアがLDAPを指し示すように変更されるため、OAAM管理コンソールにアクセスするには、LDAPにOAAMロールを作成し、それを必要なユーザーに割り当てる必要があります。
OPSS.configIdentityStore()コマンドを実行すると、次のエントリがjps.config.xmlファイルに表示されます。このエントリは、使用したLDAPのタイプと、OPSS.configIdentityStore()コマンドに指定したプロパティ・ファイルのコンテンツによって異なる場合があります。
<serviceInstance name="idstore.ldap.0" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=oaam,dc=us,dc=oracle,dc=com"/>
<property name="bootstrap.security.principal.key" value="bootstrap_idstore"/>
<property name="idstore.type" value="OPEN_LDAP"/>
<property name="ldap.url" value="ldap://example.host:1389"/>
<property name="username.attr" value="uid"/>
<property name="bootstrap.security.principal.map" value="BOOTSTRAP_JPS"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>ou=users,dc=oaam,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>ou=groups,dc=oaam,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>user.object.classes</name>
<values>
<value>person</value>
</values>
</extendedProperty>
</serviceInstance>
</serviceInstances>
Oracle Platform Security Services (OPSS)では、企業の製品開発チーム、システム・インテグレータ(SI)および独立系ソフトウェア・ベンダー(ISV)に、Java Standard Edition (Java SE)およびJava Enterprise Edition (Java EE)のアプリケーション向けに標準ベースで移植可能な企業向け統合セキュリティ・フレームワークを提供します。OPSSの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
OAAMがインストールされているマシンで、was_profile_dir/config/cells/cell_name/fmwconfigディレクトリに移動します。
例:
/scratch/xyz/IBM/WebSphere/AppServer/profiles/Dmgr04/config/cells/abc1234567Cell02/fmwconfig
jps-config.xmlをバックアップします。
jps-config.xmlをオープンします。
タグ</jpsContexts>を閉じる前に、次のJPSコンテキストを追加します。
<!-- This context is used for OAAM Juniper Integration --> <jpsContext name="idcontext"> <serviceInstanceRef ref="user.authentication.loginmodule"/> <serviceInstanceRef ref="idstore.ldap"/> <serviceInstanceRef ref="credstore"/> <serviceInstanceRef ref="keystore"/> <serviceInstanceRef ref="policystore.xml"/> <serviceInstanceRef ref="audit"/> </jpsContext>
idstore.ldapの値を、 第8.4.3項「認証プロバイダの構成」でOPSSスクリプトの実行後に作成されたIDストアのサーバー・インスタンスに変更します。
たとえば、idstore.ldapをidstore.ldap.0に変更します。
ファイルを保存して終了します。
|
注意: ファイルを保存した後で、XMLエディタを使用してすべてのタグが正しいことを確認する必要が生じることがあります。インターネット・エクスプローラでこのファイルを開いて、タグが抜けていないか確認することもできます。変更が正しい場合は、インターネット・エクスプローラでファイルを正常に開くことができます。 |
これらの変更では再起動が必要なため、IBM WebSphere管理サーバー、OAAM管理サーバー、OAAM管理対象サーバーを停止してから起動してください。
ノードとデプロイメント・マネージャを停止してノードを同期化する際に、IBM WebSphere管理者資格証明を使用します。
次の例で使用しているWAS_HOMEは/opt/IBM/WebSphere/AppServerです。
ノードを停止します。
例:
WAS_HOME/profiles/Custom01/bin/stopNode.sh -user admin_user -password admin_password
デプロイメント・マネージャを停止します。
例:
WAS_HOME/profiles/Dmgr01/bin/stopManager.sh -user admin_user -password admin_password
デプロイメント・マネージャを起動します。
例:
WAS_HOME/profiles/Dmgr01/bin/startManager.sh
ノードを同期化します。
例:
WAS_HOME/profiles/Custom01/bin/syncNode.sh localhost 8879 -user admin_user -password admin_password
ノードを起動します。
例:
WAS_HOME/profiles/Custom01/bin/startNode.sh
OAAMサーバーを再起動します。
例:
WAS_HOME/profiles/Custom01/bin/startServer.sh oaam_admin_server
WAS_HOME/profiles/Custom01/bin/startServer.sh oaam_server_server
|
注意: サーバーの再起動後にIBM WebSphere管理コンソールにログインするには、 |
SAML構成関連プロパティをインポートして、OAAMデータベースに追加されるようにします。
SAML構成関連プロパティをインポートするには、次の手順を実行します。
EnvAdminGroupロールが割り当てられている管理者としてOAAM管理コンソールにログインします。例:
http://oaam_managed_server_host:oaam_admin_managed_server_port/oaam_admin
ナビゲーション・ペインで、「環境」ノードの下の「プロパティ」をクリックします。
「プロパティ」ページで「プロパティのインポート」をクリックして、統合用にサーバー・プロパティをインポートします。
IDM_ORACLE_HOME/oaam/initディレクトリで「saml_properties.zip」を参照し、「オープン」をクリックし、「インポート」をクリックします。
インポートが完了すると、プロパティが正常にインポートされたことが表示されます。
「完了」をクリックして、インポートを完了します。
これによって、統合に必要なプロパティがインポートされます。第8.4.8項「OAAM管理コンソールを使用した統合プロパティの変更」で、使用環境に応じてこれらのプロパティを変更します。
認証局(CA)は、サード・パーティやその他のエンティティ(ユーザー、データベース、管理者、クライアント、サーバーなど)のアイデンティティを証明する信頼できる第三者機関です。認証局は、当事者の識別情報を検証し、秘密鍵で署名された証明書を付与します。
Juniper SAとOAAM間で信頼の証明書を設定するには、以降の各項に説明する手順を実行します。
最初に、証明書の秘密鍵を作成します。この秘密鍵を作成するには、次の手順を実行します。
作業ディレクトリをセキュリティ・プロパティ・ディレクトリに変更します。
WAS_HOME/java/jre/lib/security
ここでは、WAS_HOMEはAppServerディレクトリを指し示します。
WAS_HOME=/opt/IBM/WebSphere/AppServer
keytoolというキーおよび証明書管理ユーティリティを使用して、秘密鍵を作成します。cacertsをキーストアとして使用して、次のコマンドを入力します。
WAS_HOME/java/jre/bin/keytool -genkey -keyalg rsa -validity 1825 -keysize 2048 -alias OAAMCert -keystore cacerts -storepass changeit
証明書の詳細を入力します。
出力の例は次のとおりです。
What is your first and last name? [Unknown]: ag-oracle-oaam What is the name of your organizational unit? [Unknown]: Juniper What is the name of your organization? [Unknown]: Juniper What is the name of your City or Locality? [Unknown]: Sunnyvale What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=ag-oracle-oaam, OU=Juniper, O=Juniper, L=Sunnyvale, ST=CA, C=US correct? [no]: yes
|
注意: 通常、証明書の |
プロンプトが表示されたら、キーストアのパスワードを入力します。
Enter key password for <OAAMCert>
(RETURN if same as keystore password):
Re-enter new password:
このパスワードは、統合用にあとで必要になるので覚えておいてください。
秘密鍵と自己署名証明書を作成した後で、keytoolコマンドを使用して証明書署名リクエスト(CSR)を生成します。
作業ディレクトリをセキュリティ・プロパティ・ディレクトリに変更します。
WAS_HOME/java/jre/lib/security
ここでは、WAS_HOMEはAppServerディレクトリを指し示します。
WAS_HOME=/opt/IBM/WebSphere/AppServer
次のコマンドを実行して、証明書リクエストを作成します。
WAS_HOME/java/jre/bin/keytool -certreq -alias OAAMCert -file server.csr -keystore cacerts -storepass changeit
この例では、server.csrというファイルに証明書リクエストを作成しました。
このファイルは、WAS_HOME/java/jre/lib/securityディレクトリに置かれています。
server.csrファイルを/etc/pki_jungle/myCAディレクトリにコピーします。
cp WAS_HOME/java/jre/lib/security/server.csr /etc/pki_jungle/myCA/
証明書署名リクエスト(CSR)を認証局に送信して、デジタル証明書を取得します。認証局から証明書が発行されます。発行された証明書と、リクエストに署名したルートCA証明書を受信する必要があります。
テストとして、独自の認証局として行動して証明書に署名することができます。本番シナリオでは、認証局からの証明書を使用する必要があります。
本番シナリオでは、第8.4.7.4項「独自の認証局として行動」をスキップして、第8.4.7.5項「自分のキーストアに証明書をインポート」に進み、外部認証局から証明書をインポートできます。
テストの目的で、独自の認証局として行動して証明書に自己署名することができます。次の手順を1つずつ実行して、証明書の自己署名を設定します。この設定を行うには、後続の例に従って実行します。
証明書の管理、または証明書リクエストの作成に使用するマシンに、パッケージOpenSSLをインストールする必要があります。OpenSSLは、SSL (Secure Sockets Layer)プロトコルのオープン・ソースの実装です。OpenSSLは基本的な暗号機能を実装し、ユーティリティ関数を提供します。
必要なディレクトリを作成するには、次の手順を実行します。
すべての証明書ファイルが保持されるディレクトリを作成します。デフォルトのディレクトリは/etc/pki/tls/です。ルートとして次のコマンドを発行し、専用のディレクトリを作成します。
# mkdir -m 0755 /etc/pki_jungle
次のコマンドを発行して、認証局のディレクトリを作成します。
# mkdir -m 0755 \ /etc/pki_jungle/myCA \ /etc/pki_jungle/myCA/private \ /etc/pki_jungle/myCA/certs \ /etc/pki_jungle/myCA/newcerts \ /etc/pki_jungle/myCA/crl
説明:
myCAは、自分の認証局のディレクトリです。
myCA/privateは、秘密鍵が配置されるディレクトリです。すべての秘密鍵に制限的な権限を設定して、ルートのみ、またはサーバー実行の権限を持つユーザーのみが秘密鍵を読み込めるようにします。認証局の秘密鍵が盗まれると、最悪の結果が生じる可能性があります。
myCA/certsディレクトリは、サーバー証明書が配置される場所です。
myCA/newcertsディレクトリは、OpenSSLがPEM(暗号化されていない)フォーマットおよびcert_serial_number.pemフォーム(07.pemなど)で作成された証明書を入れる場所です。OpenSSLにはこのディレクトリが必要なため、必ず作成してください。
myCA/crlは、証明書取消リストが配置される場所です。
デフォルトのOpenSSL構成ファイル(openssl.cnf)を/etc/pki/tlsから自分の認証局のディレクトリにコピーして、それにopenssl.my.cnfという名前を付けるには、ルートとして次のコマンドを発行します。
# cp /etc/pki/tls/openssl.cnf /etc/pki_jungle/myCA/openssl.my.cnf
このファイルはすべてのユーザーにとって読取り可能である必要がないため、次のコマンドを発行してその属性を変更できます。
# chmod 0600 /etc/pki_jungle/myCA/openssl.my.cnf
次のコマンドを発行して、OpenSSLのデータベースとして使用できるファイルを作成します。
# touch /etc/pki_jungle/myCA/index.txt
次のコマンドを発行して、次の証明書のシリアル番号を持つファイルを作成します。
# echo '01' > /etc/pki_jungle/myCA/serial
証明書をまだ作成していないため、それを「01」に設定します。
初期構成の完了後に、他の証明書リクエストや秘密鍵に署名するために自分の認証局の証明書として使用できる自己署名証明書を生成できるようになります。
自分の認証局のディレクトリに変更します。
ルートとしてOpenSSLコマンドを発行します。
# cd /etc/pki_jungle/myCA/
これはOpenSSLの構成ファイル(openssl.my.cnf)の保存場所であるため、この場所ですべてのOpenSSLコマンドを発行する必要があります。
次に、自分の認証局の証明書と秘密鍵を作成します。ルートとして次のコマンドを発行します。
# openssl req -config openssl.my.cnf -new -x509 -extensions v3_ca -keyout private/myca.key -out certs/myca.crt -days 1825
これによって、5年間有効なデフォルトのCA拡張を持つ自己署名証明書が作成されます。
自分の認証局の秘密鍵に対してパスフレーズの入力を促すプロンプトが表示されたら、厳密なパスフレーズを設定します。
プロンプトが表示されたら、証明書リクエストに組み込まれる情報を指定します。認証局に関する情報は、次に示す例に類似しています。
Country Name (2 letter code) [GB]:GR State or Province Name (full name) [Berkshire]:Greece Locality Name (eg, city) [Newbury]:Thessaloniki Organization Name (eg, company) [My Company Ltd]:My Network Organizational Unit Name (eg, section) []:My Certificate Authority Common Name (eg, your name or your server's hostname) []:server.example.com Email Address []:whatever@server.example.com
次の2つのファイルが作成されます。
certs/myca.crt: これは自分の認証局の証明書であり、パブリックに使用可能で、すべてのユーザーが読取り可能なファイルです。
private/myca.key: これは自分の認証局の秘密鍵です。これはパスフレーズで保護されていますが、ルートのみが読み取れるようにアクセスを制限する必要があります。
自分の認証局の秘密鍵はパスフレーズで保護されていますが、ルートのみが読み取れるようにアクセスを制限する必要があります。これを実行するには、次のコマンドを発行します。
# chmod 0400 /etc/pki_jungle/myCA/private/myca.key
証明書の管理にカスタム・ディレクトリを使用しているため、/etc/pki_jungle/myCA/openssl.my.cnfを変更する必要があります。
テキスト・エディタでルートとしてopenssl.my.cnfを開き、次のセクション(35行目あたり)を検索します。
_________________________________________________________
[ CA_default ]
dir = ../../CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several certificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
#crlnumber = $dir/crlnumber # the current crl number must be
# commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = usr_cert # The extentions to add to the cert
カスタム・ディレクトリ、カスタム認証局キー(秘密鍵)、および証明書に適合するようにパス値を変更し、変更内容を保存します。
__________________________________________________________ [ CA_default ] dir = . # <--CHANGE THIS certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt #unique_subject = no new_certs_dir = $dir/newcerts certificate = $dir/certs/myca.crt # <--CHANGE THIS serial = $dir/serial #crlnumber = $dir/crlnumber crl = $dir/crl.pem private_key = $dir/private/myca.key # <--CHANGE THIS RANDFILE = $dir/private/.rand x509_extensions = usr_cert _____________________________________________________________
次に、証明書リクエストに署名し、サーバーの証明書を生成します。これを行うには、次の手順を実行します。
まず、次のコマンドを発行して、server.csr(第8.4.7.2項「証明書リクエストの作成」で作成)を自分の認証局のディレクトリにコピーします。
# cp WAS_HOME/java/jre/lib/security/server.csr /etc/pki_jungle/myCA/
次のコマンドを発行して、自分の認証局のディレクトリに変更します。
# cd /etc/pki_jungle/myCA/
さらに、次のコマンドを発行して、証明書リクエストに署名します。
# openssl ca -config openssl.my.cnf -policy policy_anything -out certs/server.crt -infiles server.csr
リクエストに署名するために、認証局の秘密鍵を指定します。openssl.my.cnfファイルでpolicy_anythingの意味を確認できます。要するに、Country、StateまたはCityに関するフィールドは、自分の認証局の証明書と一致している必要がありません。
これらの手順が完了すると、次の2つのファイルが新規に作成されます。
certs/server.crt
これはサーバーの証明書であり、パブリックに使用可能にすることができます。
newcerts/01.pem
これは同じ証明書ですが、ファイル名として証明書のシリアル番号が使われています。これは必要ありません。
これで証明書リクエスト(server.csr)は不要になったため、これを削除します。
SSL VPNは、このサーバー証明書の公開鍵をインポートして、OAAMから送信されたメッセージを復号化する必要があります。
ルートCA証明書をインポートした後で、認証局により発行された証明書をインポートする必要があります。ルート証明書の名前はmyca.crtであり、発行された証明書の名前はserver.crtです。
証明書をキーストアにインポートするには、次の手順を実行します。
作業ディレクトリをこのディレクトリに変更します。
WAS_HOME/java/jre/lib/security
ここでは、WAS_HOMEはAppServerディレクトリを指し示します。
WAS_HOME=/opt/IBM/WebSphere/AppServer
/etc/pki_jungle/myCA/certs/myca.crt and /etc/pki_jungle/myCA/certs/server.crtをWAS_HOME/java/jre/lib/securityディレクトリにコピーします。
次のkeytoolコマンドを使用して、ルート証明書をキーストアにインポートします。
WAS_HOME/java/jre/bin/keytool -importcert -alias rootCA -file myca.crt -keystore cacerts -storepass changeit
前述の構文の各要素は次のとおりです。
aliasは、ルートCA証明書の別名を表します。
rootCA -fileは、ルートCA証明書が含まれているファイルの名前を表します。
keystoreは、キーストアの名前を表します。
テキスト・エディタでserver.crtを開き、BEGIN CERTIFICATEタグとEND CERTIFICATEタグの間のコンテンツ以外のすべてを削除します。
次のkeytoolコマンドを使用して、発行された証明書をキーストアにインポートします。
WAS_HOME/java/jre/bin/keytool -importcert -alias OAAMCert -file server.crt -keystore cacerts -storepass changeit
前述の構文の各要素は次のとおりです。
aliasは証明書の別名を表します。これは、第8.4.7.1項「証明書の秘密鍵の作成」で割り当てられた秘密鍵の別名と同じである必要があります。
server.crtは、証明書が含まれているファイルの名前を表します。
keystoreは、キーストアの名前を表します。
<OAAMCert>に対するキー・パスワードを入力します。
証明書の返信はキーストアにインストールされています。
|
注意: 別名がリクエスト作成時に使用したものと同じであることを確認します。 |
統合の確立に必要なSAML構成プロパティを定義するには、次の手順を実行します。
OAAM管理コンソールにログインします。
http://oaam_managed_server_host:oaam_admin_managed_server_port/oaam_admin
「プロパティ」をダブルクリックして、プロパティ・ページを開きます。
「名前」フィールドに「oracle.saml*」と入力し、「検索」をクリックして統合プロパティを検索します。
「検索結果」で、変更するプロパティをクリックします。
「プロパティ」タブでプロパティの値を変更して、「保存」をクリックします。
統合の一環としてインポートされた、変更の必要のあるプロパティが表8-5「SAML統合プロパティ」に表示されます。
表8-5 SAML統合プロパティ
| プロパティ | 説明 |
|---|---|
|
oracle.saml.integration.version |
統合に使用されるSAMLバージョン 使用可能な値は デフォルト値は Juniper SAでもSAML2.0をサポートしています。 使用するSAMLのバージョンを決定する必要があります。 |
|
oracle.saml.target.default.url |
SAMLアサーションが成功したことをJuniper SAで検証された後にユーザーが移動するターゲットURL(ホームページ) 例: |
|
oracle.saml.keystore |
アサーションの署名に必要な証明書を格納するためのキーストアのフルパス。この例では、次のようになります。
|
|
oracle.saml.keystore.password |
キーストアのパスワード |
|
oracle.saml.keystore.certalias |
アサーションに使用する証明書の別名 |
|
oracle.saml.keystore.privatekeypassword |
秘密鍵のパスワード |
|
oracle.saml.redirect.post.url |
SAMLアサーションがポストされるURL 例: |
|
oracle.saml.set.attributes |
アサーションの一環として追加の属性をJuniper SAに送信する必要があるかどうかを指定します。 指定可能な値は デフォルト値は |
|
oracle.saml.user.attributes |
アサーションの一環として追加する必要のある属性のリスト このプロパティは、 |
|
oracle.saml.attribute.namespace |
アサーションに使用するネームスペースの名前。デフォルト値は SAML1.1の場合のみ。 |
|
oracle.saml.nameidformat |
SAMLアサーションで使用する デフォルト値は |
|
oracle.saml.nameidattribute |
SAMLアサーションでユーザーを識別する デフォルト値は
|
|
oracle.saml.issuer.url |
SAMLの発行者のURL これは、OAAM認証サーバーが実行しているマシンです。 例: |
|
oracle.oaam.juniper.intg.jps.context |
オプション 使用されるコンテキスト名。デフォルトは( |
この統合用にJuniperを構成するには、次の処理を行う必要があります。
Juniper SA構成の詳細は、次のサイトで入手可能な『Juniper Networks Secure Access管理ガイド』を参照してください。
http://www.juniper.net/techpubs
Juniper SAに認証サーバーを作成する必要があります。これを行うには、次の手順を実行します。
Juniper SSL VPN管理コンソールにログインします。
Juniper管理コンソールの左ペインで「Authentication」メニューを開き、「Auth.Servers」をクリックします。
「New」ドロップダウン・リストから「SAML Server」を選択し、「New Server」をクリックします。
表8-6の値を使用して、認証サーバーを定義します。
表8-6 認証サーバーの作成
| パラメータ | 詳細 | 値 |
|---|---|---|
|
Server Name |
SAMLServerの名前 |
OAAM SAML 1.1 表示されている値と同じものを入力します。 |
|
SAML Version |
認証サーバーのSAMLバージョン |
1.1 表示されている値と同じものを入力します。 |
|
Source Site Inter-Site Transfer Service URL |
OAAMサーバーのエントリURL。これは、認証のためにユーザーがリダイレクトされる場所です。 |
例: @ 環境に応じて、ホストとポートを指定してください。 |
|
User Name Template |
認証されたユーザーを識別する、値の抽出に使用されるテンプレート |
表示されている値と同じものを入力します。また、' |
|
Allowed Clock Skew (minutes) |
アサーションに許容されるクロックの偏り。 |
表示されている値と同じものを入力します。 |
|
SSO Method |
SAMLに使用するSSOメソッド |
|
|
Response Signing Certificate |
レスポンスの署名に使用される証明書。 |
これは、認証局から取得した証明書です。第8.4.7.5項「自分のキーストアへの証明書のインポート」で、同じ証明書をキーストアにインポートしています。 |
サーバー証明書(たとえば、第8.4.7.4.6項「証明書リクエストの署名」で作成したserver.crt)をインポートします。
「Save Changes」をクリックして、変更を保存します。
認証レルムでは、サインインするためにユーザーが満たす必要のある条件が指定されます。レルムは、認証リソースのグループで構成されます。
SAMLのユーザー・レルムを作成するには、次の手順を実行します。
Juniper管理コンソールの左ペインで「Users」メニューを開き、「User Realms」をポイントして「New User Realm」をクリックします。
名前を「OAAM SAML 1.1 User Realm」と指定します。
前の手順でこのユーザー・レルムの認証サーバーとして作成された認証サーバー「OAAM SAML 1.1」を選択します。
変更を保存します。
新規に作成されたユーザー・レルムが表示されます。
Juniper管理コンソールの左ペインで「Users」メニューを開き、「User Realms」をポイントして「OAAM SAML 1.1 User Realm」をクリックします。
OAAM SAML 1.1. User Realmで「Role Mapping」タブをクリックして、1つ以上のロール・マッピング・ルールを構成します。
Juniper SAで、認証のためにOAAMにリダイレクトされるのに必要なURLを定義するサインイン・ポリシーを作成します。
サインイン・ポリシーを作成するには、Juniper管理コンソールで「Authentication」メニューを開き、「Signing In」をポイントして「Sign-in Policies」をクリックします。
「New URL」をクリックし、表示された「Sign-in URL」フィールドで、URLとして「*/OAAM11/」と入力します。
「Sign-in」ページで、「Default Sign-in Page」を選択します。
認証レルムに対して、前に作成した「OAAM SAML 1.1 User Realm」を選択します。「User picks from a list of authentication realms」ラジオ・ボタンが選択されていることを確認します。
「Save Changes」をクリックして、それが有効になっていることを確認します。
必要なコンポーネントをすべて構成した後で、次の手順としてログイン・フローとパスワードを忘れた場合のフローをテストします。ログイン・フローおよびパスワードを忘れた場合のフローの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』の認証フローおよびパスワードを忘れた場合のフローに関する項を参照してください。統合の検証ステップについては、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』の統合の検証に関する項を参照してください。
OAAM側で統合をデバッグするには、デバッグ・ログを有効にします。ログ・ファイルの使用方法の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』の統合のデバッグに関する項を参照してください。また、Oracle Fusion MiddlewareをIBM WebSphereセルとOracle WebLogic Serverドメインで管理する場合の相違については、第3.1.2.8項「IBM WebSphereでFusion Middleware Controlを使用する場合の相違」を参照してください。
Oracle Adaptive Access ManageとJuniper Networks Secure Access (SA)との統合環境で生じる可能性のある一般的な問題の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』の一般的な問題のトラブルシューティングに関する項を参照してください。
無効なSAMLアサーションに関する問題については、次の場所でJuniper Knowledge Baseを参照できます。
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21687&cat=MAG_SERIES&actp=LIST
クロックを同期化するには、Juniper管理コンソールから「System」→「Status」→「Overview」→「System Date and Time Edit」の順に移動します。
また、Oracle Fusion MiddlewareをIBM WebSphereセルとOracle WebLogic Serverドメインで管理する場合の相違については、第3.1.2.8項「IBM WebSphereでFusion Middleware Controlを使用する場合の相違」を参照してください。
メッセージングとは、異なるタイプのアプリケーションとクライアントの間でデータを交換することです。OAAMでは、統合メカニズムの1つとしてJMS (Java Message Service)キューを使用します。OAAMは、1つ以上のJMSキューでXMLメッセージをリスニングします。Java Message Service Queue (JMSQ)とOAAMの統合により、非同期実行を有効化して、システムやデータベースに格納されている重要で機密性の高いデータへの未認可アクセスを監視および検出することができます。
この項では、IBM WebSphereアプリケーション・サーバーでの非同期デプロイメントに必要な構成および参照情報について説明します。
この項では、OAAMで使用するための非同期統合オプションのインストール手順について説明します。
非同期統合オプションをインストールする前に、次の前提条件が満たされていることを確認します。
Oracle Adaptive Access Manager 11gがインストールされ、構成済であることを確認します。非同期統合オプションは、Oracle Adaptive Access Manager 11g上にインストールされます。
Oracle Business Intelligence Publisherがインストールされ、構成済であることを確認した後で、レポート・テンプレートのインストールを実行します。非同期統合オプションには、Oracle Business Intelligence Publisherのレポート・テンプレートとして様々なレポートが含まれています。
非同期統合オプションにはインストーラは必要ありません。非同期統合オプションをインストールするには、osg_integration_kit.zipファイルを解凍するための解凍ツールが必要です。
次のディレクトリを、Oracle Adaptive Access Manager 11gがインストールされているマシンに作成します。
osg_install
osg_install/osg_integration_kit
osg_integration_kit.zipファイルのコンテンツをosg_install/osg_integration_kitディレクトリに抽出します。
OAAMでは、統合メカニズムの1つとしてJMS (Java Message Service)キューを使用します。OAAMは、1つ以上のJMSキューでXMLメッセージをリスニングします。XMLメッセージの書式の詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』のメッセージの書式のXMLスキーマ例に関する項を参照してください。
IBM WebSphereデプロイメントでは、OAAMはメッセージドリブンBeanを使用してJMSメッセージをリスニングします。メッセージドリブンBeanは、Java EEアプリケーションでメッセージを非同期に処理できるエンタープライズBeanです。メッセージドリブンBeanの定義は、osg_ejb_was.jarファイルにあります。デフォルトでは、これは、IBM WebSphereでJNDI名、eis/oaamDefault_Act_Specおよびeis/oaamHL7_Act_Specを持つJMSアクティブ化仕様を検索するように構成されています。OAAMは、この2つのJMSアクティブ化仕様に関連付けられているIBM WebSphere上のJMSキューに送信されたJMSメッセージをリスニングします。この構成を確認し、デプロイメントでの必要に応じて更新します。この項では、IBM WebSphereでJMSリソースを構成する基本例を示します。
次に、eis_oaamDefault_Act_Spec仕様のアクティブ化に対する構成例を示します。
IBM WebSphere管理コンソールにログインし、「Service Integration」→「Buses」と選択して、「oaamBus」という名前のバスを作成します。
oaamBusの「Members」で「add」をクリックして、「oaam_server1」をバス・メンバーとして追加します。
oaamBusの「Destinations」で、「oaamDefaultDestination」という名前の新しい「Queue」を追加します。
「Resources」→「JMS」→「Queue connection factories」の順に移動して、「oaamQueueConnFactory」という名前のキュー・コネクション・ファクトリを作成します。プロバイダは「Default Messaging Provider」でも構いませんが、スコープには「oaam_server1」を指定する必要があります。
「Resources」→「JMS」→「Queues」の順に移動して、「oaam_server1」のスコープを選択し、「oaamDefaultQueue」という名前のキューを作成し、「jms/oaamDefaultQueue」をJNDI名として指定し、さらに「Default Messaging Provider」をプロバイダとして指定します。
「Resources」→「JMS」→「Activation specifications」の順に移動して、次のプロパティが指定されている「oaamDefaultActSpec」という名前のアクティブ化仕様を作成します。
Scope: oaam_server1
Provider: Default Messaging Provider
JNDI: eis_oaamDefault_Act_Spec
Destination Type: Queue
Bus name: oaamBus
Target Inbound Transport Chain: InboundBasicMessaging
Provider Endpoints: host:port:BootStrapBasicMessaging (この場合のポートは、oaam_serverアプリケーション・サーバーのSIB_ENDPOINT_ADDRESSポートである必要があります)
この項では、OAAMが必要とする基本的なJMSリソースの作成方法について説明します。eis/oaamHL7_Act_Spec仕様のアクティブ化に対しても、同様のアーティファクトを作成する必要があります。特定の要件に対応するには、JMSに対するJMSリソースの作成に関してIBMのドキュメントに従ってください。JMSアクティブ化仕様、JMSキュー、およびJMSキュー・コネクション・ファクトリを含むJMSリソースのIBM WebSphere管理コンソールでの作成に関するIBMドキュメントは、次の場所で参照できます。
非同期統合機能の大半はOAAM拡張機能として実装されています。次の手順に従って、非同期統合オプション・パッケージに含まれている拡張ファイルをデプロイします。
IBM WebSphere管理コンソールにログインします。
「Applications」→「Application Types」→「WebSphere Enterprise Applications」の順にクリックします。
「oaam_server」アプリケーションの横のチェック・ボックスを選択して、「Update」をクリックします。
「Application update options」で、「Replace, add, or delete multiple files」オプションを選択し、「osg_oaam_extension_was.zip」を選択して、これをアプリケーションに追加します。これで、ほとんどの拡張ファイルがOAAMサーバー・アプリケーションに移行します。
第8.5.1.3項「JMSリソース」に示したJMSリソースがIBM WebSphereに適切に構成されていることを確認します。OAAMは、JNDI名のeis/oaamDefault_Act_Specおよびeis/oaamHL7_Act_Specを持つIBM WebSphere JMSアクティブ化仕様を使用するように構成されています。JMSキュー、JMSキュー・コネクション・ファクトリ、サーバー統合バスも、第8.5.1.3項「JMSリソース」で説明するように、ターゲットのJMSアクティブ化仕様を指定してIBM WebSphereに適切に構成する必要があります。
同様に、ステップ1 - 3を実行し、さらに「Application update options」で「Replace or add a single module」オプションを選択し、「osg_ejb_was.jar」を選択して、これをアプリケーションに追加します。「oaam_server1」が選択されていて、サーバーへのモジュールのマップの手順でこのモジュールにマップされていることを確認します。
ノードを同期化し、OAAMサーバーのアプリケーション・サーバーを再起動します。
JMSリスナーを実装することにより、XML形式のメッセージに関してJMSキュー(またはトピック)をリスニングするようにOracle Adaptive Access Managerを構成できます。JMSメッセージのコンテンツは、OAAMのWeb Services APIコールと類似しています。次に、サンプルのJMSメッセージの書式を示します。
VCryptTracker.updateLog
VCryptTracker.createTransaction
VCryptTracker.updateEntity
VCryptRulesEngine.processRules
OAAMでのJMS統合の概要とサンプルXMLについては、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』を参照してください。
JMS統合の様々な要素は、OAAMのプロパティとユーザー定義列挙を使用して構成できます。
統合に使用されるJMS構成プロパティのリストは、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』を参照してください。次のプロパティは、IBM WebSphereのデプロイメントには関連していません。
oracle.oaam.jms.listeners.default.initial.context.factory
oracle.oaam.jms.listeners.default.connection.factory
oracle.oaam.jms.listeners.enum.lsnr_1
oracle.oaam.jms.listeners.enum. lsnr_1.type
oracle.oaam.jms.listeners.enum. lsnr_1.url
oracle.oaam.jms.listeners.enum. lsnr_1.jndiname
oracle.oaam.jms.listeners.enum.lsnr_1.initial.context.factory
oracle.oaam.jms.listeners.enum.lsnr_1.connection.factory
oracle.oaam.jms.listeners.enum. lsnr_1.processor
oracle.oaam.jms.listeners.enum. lsnr_1.instancecount
監視するキュー(またはトピック)ごとに、ユーザー定義列挙oracle.oaam.jms.listeners.enumに列挙要素を追加して、1つのリスナーを構成する必要があります。リスナー・リストまたはプロパティを変更する場合は、リスナーが実行しているOAAMサーバーを再起動する必要があります。
OAAMのデフォルトのJMSメッセージ・プロセッサでは、タイプjavax.jms.TextMessageのみが処理されます。このプロセッサでは、その他のタイプのメッセージは無視されます。他のタイプのメッセージを処理するには、oracle.oaam.jms.JmsAbstractMessageProcessorまたはoracle.oaam.jms.JmsDefaultMessageProcessorのいずれかを拡張してカスタム・プロセッサを実装します。標準のメッセージドリブンBeanクラスを開発し、それをosg_ejb_was.jar/META-INF/ibm-ejb-jar-bnd.xmiにあるIBM WebSphere JMSアクティブ化仕様と関連付けます。参照をosg_ejb_was.jar内のJMSアクティブ化仕様に追加した後で、第8.5.1.4項「非同期統合拡張ファイルのデプロイ」の説明に従って、jarファイルをOAAMサーバーのアプリケーションに再デプロイする必要があります。
さらに、TextMessageのコンテキストが、この項の末尾に示すXMLスキーマに準拠したXML文字列であるかぎり、デフォルトのJMSメッセージ・プロセッサによる処理が行われます。
Oracle Adaptive Access Managerでは、エンティティとトランザクションをデータ・フィールド数の制限なしに定義できます。さらに、トランザクションはエンティティを参照するように定義することもできます。Oracle Adaptive Access Managerでは、エンティティ・データとトランザクション・データがデータベースに永続化されます。
次のトピックについては、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』を参照してください。
SQLスクリプト・ファイルの生成
エンティティ・ビューの詳細
トランザクション・ビューの詳細
識別子
サポートされるデータベース
非同期統合オプション・パッケージには、指定されたPython式を実行するOAAM条件が含まれています。この条件は、osg_install/osg_integration_kit/osg_rule_conditions.zipからインポートできます。
Python式を実行するには、jython.jarライブラリが必要です。jython.jarの場所は次のとおりです。
ORACLE_MW_HOME/ oracle_common/modules/oracle.jrf_11.1.1/jython.jar
次の手順を実行して、jython.jarをOAAMサーバー・アプリケーションの共有ライブラリとして追加します。
IBM WebSphere管理コンソールにログインします。
「Environment」→「Shared libraries」→「New」の順にクリックします。
このjarに名前を指定し、jython.jarへのパスを指定します。
変更を適用します。
「Applications」→「Application Types」→「WebSphere Enterprise Applications」→「oaam_server_11.1.2.0.0」の順に移動します。
OAAMサーバー・アプリケーションの詳細で、「Configuration」タブから「References」セクションに移動し、「shared library references」をクリックし、「OAAM_Runtime」を選択して「Reference Shared libraries」をクリックします。
jythonライブラリを選択したリストに移動して、変更を適用します。
ノードを同期化し、OAAMサーバーのアプリケーション・サーバーを再起動します。
Python式からアクセス可能なオブジェクト(変数)のリストは、『Oracle Fusion Middleware Oracle Adaptive Access Manager開発者ガイド』を参照してください。
OAAMサンプル・アプリケーションは、OAAM APIの理解を深められるようにドキュメントの形式で用意されています。これは、API使用方法の基本的な要素のみを提供しているため、本番コードとしての使用を対象としていません。ネイティブ統合を実装しているカスタマは、サンプル・アプリケーションを参照用として使用し、独自のアプリケーションを開発する必要があります。OAAMサンプル・アプリケーションと関連ファイルは、My Oracle Support (https://support.oracle.com)からダウンロードできます。
この項では、ネイティブIn-ProcベースのOAAMサンプル・アプリケーションの設定方法について説明します。
ネイティブIn-ProcベースのOAAMサンプル・アプリケーションを設定するには:
oaam_sampleディレクトリを作成します。
oaam_sample_inproc.zipファイルをoaam_sampleディレクトリに抽出します。
oaam_sample/WEB-INFディレクトリにあるweb.xmlファイルをテキスト・エディタでオープンし、</web-app>タグの上の最後のセクションとして次の行を追加します。
<resource-ref>
<res-ref-name>jdbc/OAAM_SERVER_DB_DS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<resource-ref>
oaam_sampleディレクトリに移動し、次のコマンドを実行して、IBM WebSphere管理コンソール用にOAAMサンプルWARファイルを作成します。
jar cfm ../oaam_sample_inproc_was.war META-INF/MANIFEST.MF .
このコマンドを実行すると、oaam_sample_inproc_was.warファイルが生成されるので、このファイルをIBM WebSphere管理コンソールにインストールします。
IBM WebSphere管理コンソールにログインし、コンソール・ナビゲーション・ツリーで「Applications」を開き、さらに「Application Types」を開いて「WebSphere enterprise applications」をクリックし、アプリケーションのリストをオープンします。
「oaam_server_11.1.2.0.0」アプリケーションの横のチェック・ボックスを選択して、「Update」をクリックします。
「Replace or add a single module」を選択して一意のパス(oaam_sampleなど)を指定し、ステップ4で作成されたoaam_sample_inproc_was.warファイルへのパスを指定した後で、「Next」をクリックしてステップ2のページに進みます。
これがoaam_server1に適用されていることを確認します。また、「Resource Reference」ページでモジュール用にjdbc/OAAM_SERVER_DB_DSが選択されていることを確認します。
設定を変更しないでその他の構成手順を続行し、変更内容を保存して同期化します。
oracle.security.jps.was.deployment.jarをWAS_HOME/pluginsディレクトリに移動して、ノードおよびデプロイメント・マネージャを再起動します。このようにしないと、WAR/JARファイルをモジュールとしてアプリケーションに追加する作業が失敗します。
IBM WebSphere管理コンソールで「Applications」→「Application Types」→「WebSphere enterprise applications」→「oaam_server_11.1.2.0.0」→「Context Root for Web Modules」の順に移動して、OAAMサンプルWebモジュールに「oaam_sample」を指定します。
oaam_native_libsディレクトリを、was_native_jarディレクトリからoaam_serverがインストールされているディレクトリにコピーします。
IBM WebSphere管理コンソールで「Environment」→「Shared Libraries」と移動して、セルのスコープを「oaam_server1」として選択します。
「oaam_native_libs」という名前の新しい共有ライブラリを作成し、そのクラスパスをステップ10で作成したディレクトリへのパスとして指定します。
IBM WebSphere管理コンソールで「Applications」→「Application Types」→「WebSphere enterprise applications」→「oaam_server_11.1.2.0.0」→「Shared library references」の順に移動して、「oaam_sample」Webモジュールの横のチェック・ボックスを選択します。
「Reference Shared libraries」をクリックして、ステップ12で作成した共有ライブラリを「Available」リストから「Selected」リストに移動します。その後で、変更を保存して同期化します。
ステップ10でコピー先となったディレクトリから「was_native_jars/was_native_web.jar」をデプロイします。「Applications」→「Application Types」→「WebSphere Enterprise Applications」の順に移動して、「oaam_server_11.1.2.0.0」アプリケーションの横のチェック・ボックスを選択し、「Update」をクリックします。
「Application update options」セクションの下で「Replace or add a single module」を選択し、「Specify the path beginning with the installed application archive file to the module to be replaced or added」フィールドで一意のパス(oaam_sample_webなど)を指定し、was_native_web.jarファイルへのパスを選択し、「Next」をクリックしてステップ2のページに進みます。これがoaam_server1に適用されていることを確認します。設定を変更しないで構成を続行し、変更内容を保存して同期化します。
oracle.security.jps.was.deployment.jarをWAS_HOME/pluginsディレクトリに移動して、ノード/マネージャを再起動します。
「Servers」→「Server types」→「WebSphere application servers」の順に選択して、oaam_serverアプリケーション・サーバーを再起動します。
OAAM管理コンソールにログインします。
oaam_policies.zipファイルからポリシーをインポートします。
oaam_kba_questions_en.zipファイルからチャレンジ質問をインポートします。
Sample_Transaction_Defs.zipファイルからトランザクション定義をインポートします。
Sample_Txn_Models.zipファイルからトランザクション・ポリシーをインポートします。
次のURLに移動します。
http://host-name:oaam-server-port/oaam_sample
OAAMサンプル・アプリケーションのログイン・ページが表示されます。
ユーザー名を入力し、次ページにパスワードを入力します。登録プロセスを経た後で、サンプル・トランザクションへのリンクが表示されます。
|
注意: 最初のログイン時のパスワードは |
ステップ8で「oracle.security.jps.was.deployment.jar」を移動してノード/マネージャを再起動した場合は、それをWAS_HOME/pluginsディレクトリに戻します。そうしないと、アクセス制御は完全に無効になります。
この項では、ネイティブSOAPベースのOAAMサンプル・アプリケーションの設定方法について説明します。
SOAPベースのOAAMサンプル・アプリケーションを設定するには、次の手順を実行します。
oaam_sampleディレクトリを作成します。
oaam_sample_soap.zipファイルをoaam_sampleディレクトリに抽出します。
customer application deployment/WEB-INF/classesディレクトリで、テキスト・エディタを使用してoaam_custom.propertiesファイルを次のように編集します。
vcrypt.tracker.soap.urlプロパティを設定します。
vcrypt.tracker.soap.url=http://host-name:port/oaam_server/services
この設定によって、アプリケーションが通信するWebサービスの場所が指定されます。
bharosa.image.dirlistを、OAAMイメージが格納されている絶対ディレクトリ・パスに設定します。
暗号化鍵に関連するプロパティbharosa.cipher.encryption.algorithm.enumを削除します。
oaam_sampleディレクトリに移動し、次のコマンドを実行します。
jar cfm ../oaam_sample_soap_was.war META-INF/MANIFEST.MF .
これによってoaam_sample_soap_was.warファイルが生成されるので、このファイルをIBM WebSphere管理コンソールを使用してインストールします。
IBM WebSphere管理コンソールで、「Applications」→「Application Types」→「WebSphere enterprise applications」の順に移動します。
「Enterprise Applications」リストから、「oaam_server_11.1.2.0.0」アプリケーションの横のチェック・ボックスを選択して、「Update」をクリックします。
「Application update options」セクションで「Replace or add a single module」を選択して一意のパス(oaam_sampleなど)を指定し、ステップ4で作成されたoaam_sample_soap_was.warファイルへのパスを指定した後で、「Next」をクリックしてステップ2のページに進みます。設定を変更しないで構成を続行し、変更内容を保存して同期化します。
モジュールがoaam_server1に適用されていることを確認します。
oracle.security.jps.was.deployment.jarをWAS_HOME/pluginsディレクトリに移動して、ノードおよびデプロイメント・マネージャを再起動します。
IBM WebSphere管理コンソールで「Applications」→「Application Types」→「WebSphere enterprise applications」→「oaam_server_11.1.2.0.0」→「Context Root for Web Modules」の順に移動して、OAAMサンプルWebモジュールに「oaam_sample」を指定します。
oaam_native_libsディレクトリを、was_native_jarディレクトリからoaam_serverがインストールされているディレクトリにコピーします。
IBM WebSphere管理コンソールで「Environment」→「Shared Libraries」と移動して、セルのスコープを「oaam_server1」として選択します。
「oaam_native_libs」という名前の新しい共有ライブラリを作成し、そのクラスパスをステップ10で作成したディレクトリへのパスとして指定します。
IBM WebSphere管理コンソールで「Applications」→「Application Types」→「WebSphere enterprise applications」→「oaam_server_11.1.2.0.0」→「Shared library references」の順に移動して、「oaam_sample」Webモジュールの横のチェック・ボックスを選択します。
「Reference Shared libraries」をクリックして、ステップ12で作成した共有ライブラリを「Available」リストから「Selected」リストに移動します。変更を保存して同期化します。
ステップ10でコピー先となったディレクトリから「was_native_jars/was_native_web.jar」をデプロイします。コンソールのナビゲーション・ツリーで、「Applications」を開き、「Application Types」を選択して、「WebSphere enterprise applications」をクリックし、アプリケーションのリストを開きます。
「Enterprise Applications」リストから、「oaam_server_11.1.2.0.0」アプリケーションの横のチェック・ボックスを選択して、「Update」をクリックします。
「Replace or add a single module」を選択して一意のパス(oaam_sample_webなど)を指定し、was_native_web.jarファイルへのパスを選択し、「Next」をクリックしてステップ2に進みます。設定を変更しないで構成を続行し、構成を保存します。
oracle.security.jps.was.deployment.jarをWAS_HOME/pluginsディレクトリに戻して、ノード/マネージャを再起動します。
「Servers」→「Server types」→「WebSphere application servers」の順に選択して、oaam_serverアプリケーション・サーバーを再起動します。
OAAM管理コンソールにログインします。
oaam_policies.zipファイルからポリシーをシステムにインポートします。
oaam_kba_questions_en.zipファイルからチャレンジ質問をシステムにインポートします。
Sample_Transaction_Defs.zipファイルからトランザクション定義をシステムにインポートします。
Sample_Txn_Models.zipファイルからトランザクション・ポリシーをシステムにインポートします。
次のURLに移動します。
http://host-name:oaam-server-port/oaam_sample
サンプル・アプリケーションのログイン・ページが表示されます。
