| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11gリリース1(11.1.1) B56235-07 |
|
 前 |
 次 |
OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。ポリシー、資格証明、キーおよび証明書の概要は、次の各項を参照してください。
この章では、ポリシー、資格証明およびキーに共通のOPSSセキュリティ・ストアの機能について説明します。この章の内容は次のとおりです。
Java EEおよびWebLogicのセキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のJava EEおよびWebLogicのセキュリティに関する項を参照してください。
|
注意: この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。 |
OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。
OPSSセキュリティ・ストアは、選択したリポジトリ・タイプに応じてファイルベース、LDAPベース、またはDBベースにすることができます。また、ファイルベースからLDAPまたはDBベース、DBベースからLDAPまたはDBベース、LDAPベースからLDAPまたはDBベースに再関連付けができます(つまり、リポジトリ・タイプは変更可能ということです)。これ以外の再関連付けはサポートされていません。OPSSセキュリティ・ストアの再関連付けに使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した再関連付けおよびスクリプトreassociateSecurityStoreを使用した再関連付けの項を参照してください。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。
Java EEアプリケーションに関するセキュリティ・データは、通常、アプリケーションとともにパッケージされているため、デプロイ時にOPSSセキュリティ・ストアに移行できます。OPSSセキュリティ・ストアへの移行に使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した移行およびスクリプトmigrateSecurityStoreを使用した移行の項を参照してください。
LDAPベースのポリシー・ストアは、通常、本番環境で使用します。今回のリリースでサポートされているLDAPサーバーは、Oracle Internet Directory(リリース10.1.4.3以降)のみです。
ドメインでLDAPベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。
サービス・インスタンスで指定可能なプロパティの一覧は、付録F「LDAPベースのすべてのインスタンスに共通するプロパティ」を参照してください。
この項の内容は次のとおりです。
複数のサーバー・インスタンスが複数のマシンにわたって分散されている環境では、OPSSセキュリティ・ストアを、管理サーバーで構成したLDAPベースまたはDBベースのストアで集中管理することを強くお薦めします。
ファイルベースの複数ノード・サーバー・ドメインの場合(推奨されていません)、JMXフレームワークでは、管理サーバーで加えられた変更が、ドメインの管理対象サーバーの実行時環境に定期的に伝搬されます。これらの実行時環境それぞれのデータは、キャッシュ・ポリシーおよびプロパティ値に基づいてリフレッシュされます。ファイルベースのセキュリティ・ストアに対する変更はすべて、ドメイン管理サーバー(管理対象サーバーではない)で実行することが重要です。
ポリシーおよび資格証明に設定可能なプロパティの詳細は、付録F「ポリシー・ストアのプロパティ」および付録F「資格証明ストアのプロパティ」を参照してください。
LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directoryのみです。Oracle Internet Directoryに正しくアクセスできるようにするには、後述する手順で、ノードをサーバー・ディレクトリに設定する必要があります。
Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。これらの必要な資格証明を手動で指定する場合は、第21.5.7項「ブートストラップ資格証明の手動による指定」を参照してください。
Oracle Internet Directoryサーバーのノードの設定
次の手順は、Oracle Internet Directory管理者が実行します。
LDAP Oracle Internet Directoryにノードを設定する手順は、次のとおりです。
次のDNエントリおよびCNエントリを指定するLDIFファイル(ここではjpstestnode.ldifというファイル名にします)を作成します。
dn: cn=jpsroot cn: jpsroot objectclass: top objectclass: OrclContainer
ルート・ノードの識別名(前述の例では文字列jpsrootで示す)は、他のどの識別名とも異なる名前にする必要があります。一部のLDAPサーバーでは、デフォルトで大文字小文字が区別されます。1つのルート・ノードを複数のWebLogicドメインで共有できます。このノードは、サブツリーに対する読取りと書込みの権限がOracle Internet Directory管理者に付与されていれば、最上位レベルに作成する必要はありません。
次の例に示すように、コマンドldapaddを使用してこのデータをLDAPサーバーにインポートします(コマンド呼出し内で改行しないでください)。
>ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -v -f jpstestnode.ldif
次の例に示すように、コマンドldapsearchを使用してノードが正常に挿入されたことを確認します(コマンド呼出し内で改行しないでください)。
>ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -s base -b "cn=jpsroot" objectclass="orclContainer"
次の例に示すように、ユーティリティoidstats.sqlを実行して、データベースのパフォーマンスを最適にするためにデータベース統計を生成します。
>$ORACLE_HOME/ldap/admin/oidstats.sql
このユーティリティは、初期プロビジョニングを行った後に実行する必要があります。このユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Managementリファレンスを参照してください。
ポリシー・ストアの再関連付けを行う場合は、「OPSSセキュリティ・ストアの再関連付け」を参照してください。
この項では、Oracle WebLogic ServerまたはJava SEアプリケーションと、LDAP Oracle Internet Directory間で一方向SSLチャネルを設定する方法を説明します。このような接続は、たとえばLDAPベースのターゲット・ストアへの再関連付けを行う場合に必要になります。
前提条件: Oracle Internet Directoryサーバーの構成
一方向SSLモードでリスニングするようにOracle Internet Directoryサーバーを構成する方法は、『Oracle Fusion Middleware管理者ガイド』のOracle Internet DirectoryリスナーでのSSLの有効化に関する項を参照してください。
Oracle Internet Directoryの認証局(CA)のエクスポート
orapkiを使用して証明書を作成する必要があるのは、Oracle WebLogicサーバーでCAを認識できない場合のみです。
次の例は、このコマンドを使用して証明書serverTrust.certを作成する方法を示しています。
>orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert
前述の呼出しを実行すると、キーストア・パスワードの入力を求められます。
開始する前に
SSLを構成する前に、次のことに注意してください。
確立されているSSLのタイプがサーバー認証の場合は、次の手順が必要です。それ以外(認証なしまたはクライアント認証)の場合には、次の手順は不要です。
次の手順で指定するフラグを複数アプリケーション環境で使用する場合は、それらすべてのアプリケーションでトラスト・ストアを共有する必要があります。
Java EEアプリケーションの場合のWebLogic Serverの設定
アイデンティティ・ストア・サービスとポリシー・ストア・サービスでは、使用するソケット・ファクトリが異なるため、次の手順も異なります。
サーバーとアイデンティティ・ストア間で一方向SSL接続を確立する手順は、次のとおりです(信頼できるCAがある場合は、エクスポートされていることが前提となります)。
Oracle WebLogicサーバーでCAを認識できる場合は、この手順を省略します。CAを認識できない場合は、ユーティリティkeytoolを使用してOracle Internet DirectoryのCAをWebLogicトラストストアにインポートします。
ファイルmyKeys.jksを出力する次の呼出しは、このコマンドを使用してファイルserverTrust.certをインポートする方法を示しています。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
サーバーを起動するスクリプト(通常はstartWebLogic.sh)に次のような行を追加して変更し、サーバーを再起動します。
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
サーバーとポリシー・ストア間で一方向SSL接続を確立する手順は、次のとおりです(信頼できるCAがある場合は、エクスポートされていることが前提となります)。
ユーティリティkeytoolを使用して、次の呼出しのように、信頼できるCAをトラスト・キー・ストアにインポートします。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
サーバーを起動するスクリプト(通常はstartWebLogic.sh)に次のような行を追加して変更し、サーバーを再起動します。
-Dweblogic.security.SSL.trustedCAKeyStore=<absolute path name to file myKeys.jks>
OIDサーバーのSSL証明書でワイルド・カードを使用する場合は、WebLogic Serverを起動するスクリプトに次の行を追加します。
-Dweblogic.security.SSL.ignoreHostnameVerification=true
Java SEアプリケーションの場合のWebLogic Serverの設定
Java SEアプリケーションの場合、アイデンティティ・ストア・サービスとポリシー・ストア・サービスの設定は同じです。
Oracle WebLogicサーバーでCAを認識できる場合は、この手順を省略します。CAを認識できない場合は、ユーティリティkeytoolを使用してOracle Internet DirectoryのCAをWebLogicトラストストアにインポートします。
ファイルmyKeys.jksを出力する次の呼出しは、このコマンドを使用してファイルserverTrust.certをインポートする方法を示しています。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
JMVを起動するスクリプトを変更して、次のような行を追加します。
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
DBベースのセキュリティ・ストアは、通常、本番環境で使用します。本番環境でサポートされているDBベースのセキュリティ・ストアは、Oracle RDBMS(リリース10.2.0.4以降、リリース11.1.0.7以降およびリリース11.2.0.1以降)のみです。
|
注意: 開発環境でのみ、OPSSセキュリティ・ストアとして、Oracle RDBMS Express、Oracle RDBMS Standard EditionおよびOracle RDBMS Standard Edition Oneを使用できます。 |
DBベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。サーバーが初期化を完了する前になんらかのチェックが必要な場合は、第L.15項「サーバー起動前のパーミッション・チェックの失敗」を参照してください。
構成可能なプロパティの一覧は、付録F「OPSS構成プロパティ」を参照してください。
この項の内容は、次のとおりです。
OPSSセキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。
RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』の「リポジトリ作成ユーティリティの概要」および「リポジトリ作成ユーティリティの実行」の章を参照してください。
スキーマの作成および初期データのシードについては、次の各項で説明します。
RCUを使用して、OracleデータベースにOPSSスキーマを作成する手順は、次のとおりです。
RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの作成」ページを表示します。
そのページで「作成」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。
そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。
続いて、「次へ」をクリックすると、入力したデータがチェックされ、作成前の操作が実行されます。このチェックが正常に終了すると、「コンポーネントの選択」ダイアログが表示されます。
そのダイアログで、既存スキーマの接頭辞を使用するか、新規の接頭辞を作成するかを選択して、スキーマにインストールするOPSSコンポーネントを選択します。
コンポーネントを選択したら、「次へ」をクリックして、「スキーマ・パスワード」ダイアログを表示します。ダイアログでパスワードを入力したら、「次へ」をクリックして、「表領域のマップ」ダイアログを表示します。このダイアログには表領域のサマリーが表示されます。デフォルト表領域を1つと一時表領域を1つ使用します。デフォルトの表領域名は、それぞれPREFIX_IAS_OPSSおよびPREFIX_IAS_TEMPです。
デフォルト以外の表領域またはデータファイルを作成する場合は、「表領域の管理」ボタンをクリックして、「表領域の管理」ダイアログを表示します。表示されたダイアログで、表領域またはデータファイルを作成するための情報を入力します。入力が終了したら、「OK」をクリックします。入力した表領域がデータベースにまだ存在しない場合は、その表領域が作成され、その内容が、表領域の作成中に表示されます。「OK」をクリックすると、「サマリー」ダイアログに、入力したデータのサマリーが表示されます。続いて、「作成」をクリックして、追加の表領域またはデータファイルの作成を有効にします。
作成が完了すると、「完了サマリー」に、データベースの詳細が表示されます。
次に示すようにSQLPlusコマンドを呼び出して、データベース・スキーマが適切に作成されていることを確認します。
SQL> desc <schemaPrefix>.jps_dn;
schemaPrefixは、前述の手順4で設定した接頭辞です。
OPSSスキーマの削除は、OPSSセキュリティ・ポリシーの格納用としてそのDBを使用しなくなった場合にのみ必要です。
OPSSスキーマが正常に作成された後で、RCUを使用して、次のようにOPSSスキーマを削除します。
RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの削除」ページを表示します。
そのページで「削除」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。
そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。続いて、「次へ」をクリックして、「コンポーネントの選択」ダイアログを表示します。
そのダイアログで、接頭辞を選択し、「コンポーネント」階層で、「AS共通スキーマ」および「Oracle Platform Security Services」を選択します。「次へ」をクリックして「サマリー」ページを表示します。
そのページで、収集された詳細情報が正しいことを確認し、「削除」をクリックして削除処理を起動します。正常に処理が完了すると、「完了サマリー」ページに、削除されたスキーマの詳細情報が表示されます。
Oracle WebLogic管理コンソールを使用してWebLogicドメイン内にJDBCデータソースを作成するには、次の手順を実行します。
コンソールにログインし、「サービス」→「データソース」に移動して、「新規」→「汎用データソース」を選択します。
「JNDI名」を入力し、「次へ」をクリックします。この名前は、jps-config.xmlファイルでのDBベース・ストアの構成に使用することに注意してください。
「データベース・ドライバ」プルダウンで、「Oracleのインスタンス接続用ドライバ(Thin)、バージョン:9.0.1以降」(これは非XA JDBCドライバです)を選択し、「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択が解除されていることを確認し、「次へ」をクリックします。
「接続プロパティ」領域で、「データベース名」、「ホスト名」、「ポート」、「データベース・ユーザー名」および「パスワード」にデータを入力します。「次へ」をクリックします。
設定を検証してテストし、問題がなければ「終了」をクリックします。
作成したデータソースを管理サーバーにデプロイします。このデータソースをドメイン内のすべてのサーバーのターゲットとする必要があります。
WebSphere Application Serverでデータソースを設定するには、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。
|
注意: 11.2のOracle JDBCドライバでは、Etc/UCT、UCT、Etc/UTC、Etc/Universal、Etc/ZuluおよびUniversalのタイムゾーンは非推奨です。Oracle JDBCドライバのタイムゾーンを設定したら、そのタイムゾーンが、非推奨ではないことを確認してください。 |
この項では、管理者がDBベースのセキュリティ・ストアをメンテナンスする場合に実行する可能性のある一部のタスクについて説明します。
DBベースのセキュリティ・ストアには、変更ログが保持されますが、このログは定期的にパージする必要があります。変更ログをパージするには、管理者が、提供されているSQLスクリプトopss_purge_changelog.sqlを使用して、24時間以上前の変更ログをパージするか、データベースに接続して、次の行で示すように、SQLのdeleteを(適切な引数を指定して)実行します。
SQL>delete from jps_changelog where createdate < (select(max(createdate) - 1) from jps_changelog); SQL>Commit;
DBベースのセキュリティ・ストアにアクセスする際に、OPSS管理APIの実行速度が遅い場合は、DBMS_STATSパッケージを実行して、DBの表、索引、クラスタの物理記憶域に関する統計情報を収集します。この情報はデータ・ディクショナリに格納され、分析対象のオブジェクトにアクセスするSQL文の実行計画を最適化する際に使用できます。
数千の新しいアプリケーション・ロールを作成する場合など、大量のデータをDBベースのセキュリティ・ストアにロードする場合は、短期間内にロード・アクティビティと同時にDBMS_STATSを実行することをお薦めします。それ以外で、ロード・アクティビティが小規模な場合は、DBMS_STATSを必要に応じて1回のみ実行する必要があります。
次のサンプルは、DBMS_STATSの使用例を示しています。
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('DEV_OPSS', DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);
DEV_OPSSは、RCUの設定時(「OracleデータベースでのOPSSスキーマの作成」の項を参照)に作成されたDBスキーマの名前です。DBMS_STATSパッケージの詳細は、『Oracle Database管理者ガイド』を参照してください。
DBMS_STATSを定期的に実行するには、次に説明するように、シェル・スクリプトまたはSQLスクリプトを使用します。
次のサンプル・スクリプトは、コマンドDBMS_STATSを10分ごとに実行します。
#!/bin/sh i=1 while [ $i -le 1000 ] do echo $i sqlplus dev_opss/welcome1@inst1 @opssstats.sql sleep 600 i=`expr $i + 1` done
opssstats.sqlには、次のテキストが含まれます。
EXEC DBMS_STATS.gather_schema_stats('DEV_OPSS',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);
QUIT;
また次のサンプルSQLスクリプトも、コマンドDBMS_STATSを10分ごとに実行します。
variable jobno number;
BEGIN
DBMS_JOB.submit
(job => :jobno,
what => 'DBMS_STATS.gather_schema_stats(''DEV_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
interval => 'SYSDATE+(10/24/60)');
COMMIT;
END;
/
前述のSQLスクリプトによるDBMS_STATSの定期的な起動を停止するには、最初に次のコマンドを発行してそのジョブ番号を見つけます。
sqlplus '/as sysdba'
SELECT job FROM dba_jobs WHERE schema_user = 'DEV_OPSS' AND what = 'DBMS_STATS.gather_schema_stats(''DEV_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);';
続いて、次のようなコマンドを発行します。このコマンドでは、前述の問合せがジョブ番号31を返すと仮定しています。
EXEC DBMS_JOB.remove(31);
Java SEアプリケーション用のストア構成の例は、第23.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。
Java EEアプリケーション用のストア構成の例は、例1を参照してください。
その他のアーティファクトの構成の詳細は、「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。
OPSSセキュリティ・ストアの再関連付けとは、ポリシー、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみサポートされています。DBタイプのターゲットでは、DB_ORACLEのみサポートされています。
再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。再関連付けでは、各セキュリティ・アーティファクトに対して、ターゲット・ストアを検索し、一致するストアが見つかった場合は、一致するアーティファクトが更新され、見つからない場合は、新しいアーティファクトが作成されます。
再関連付けを実行する代表的な例として、すぐに使用可能なファイルベース・ストアのかわりに、LDAPベースまたはDBベースのOPSSストアをドメインで使用するように設定する場合があります。この操作は、OPSSストアの構成およびインスタンス化の後であればいつでも行うことができます。また、この操作は、次の項で説明されているように、Fusion Middleware ControlまたはreassociateSecurityStoreのいずれかを使用して実行します。
再関連付けでは、OPSSポリシー・ストア(ポリシー、資格証明、およびキー)をリポジトリ間で移行し、適切なセキュリティ・ストア・プロバイダを構成します。この項では、Fusion Middleware Controlのページを使用して再関連付けを行う方法を説明します。
「セキュリティ・プロバイダ構成」ページのその他の使用方法は、「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。
重要ポイント
ターゲットのLDAPストアに再関連付けを行う前に、「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。
ターゲットのDBストアに再関連付けを行う前に、「DBベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。
再関連付けでターゲットLDAPへの一方向SSLが必要な場合は、再関連付けを行う前に、「LDAPへの一方向SSL接続の設定」の手順を実行してください。
LDAPストアへの再関連付けの後、Oracle Internet Directoryストアのルート・ノードへのアクセスを保護するために、「Oracle Internet Directoryノードへのアクセスの保護」で説明する手順を実行してください。
再関連付けで生成されたjps-config.xmlファイルは、Java EEアプリケーションにのみ適しています。Java SEアプリケーションの場合は、第23.1.3項「DBベースのOPSSセキュリティ・ストアの構成」に記載されている構成と一致するようにjps-config-jse.xmlファイルを編集してください。
Fusion Middleware Controlを使用してOPSSセキュリティ・ストアを再関連付けする手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」(Oracle WebLogic Serverに接続している場合)、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」(WebSphere Application Serverに接続している場合)に移動して、「セキュリティ・プロバイダ構成」ページを表示します(次の図にページの一部を示します)。
「セキュリティ・ストア」領域の表には、現在ドメインで構成されているプロバイダの特性が表示されます。
「アソシエーションの変更」ボタンをクリックして、「セキュリティ・プロバイダの設定」ページを表示し、プルダウン・リストから「ストア・タイプ」を選択します。このページに表示されるテキストは、選択したストア・タイプによって異なります。次の図に、Oracle Internet Directoryを選択した場合のこのページの一部を示します。
「データベース」を選択している場合は、「データソース名」ボックスにデータソース名を入力します。これは、データソースの作成時に入力したJDBCデータソース名にする必要があります(詳細は、「データソース・インスタンスの作成」を参照)。必要に応じて、「選択」をクリックして、構成済のデータソース名のリストを取得します。
「Oracle Internet Directory」を選択している場合は、「LDAPサーバーの詳細」領域で、ターゲットのLDAPサーバーの詳細と接続情報を入力します。
ターゲットのOracle Internet Directory LDAPサーバーのホスト名とポート番号を入力します。
オプションで、「SSLを接続に使用」ボックスを選択し、LDAPサーバーへの匿名SSL伝送を確立します。
このチェック・ボックスを選択するときには、次の点に注意してください。
ターゲットLDAPサーバーのポートは、匿名SSL伝送を処理するように構成されている必要があります。このポートは、デフォルトの(セキュアではない)LDAPサーバー・ポートとは異なります。
再関連付けでターゲットLDAPストアへの一方向SSLを使用する場合は、この手順を実行する前に、「LDAPへの一方向SSL接続の設定」で説明する手順を必ず実行してください。一方向SSL接続の設定で、一方向SSLチャネルをサポートするポートを特定し、以降の手順でそのポートを指定します。今回のリリースでは、双方向SSLチャネルを使用した再関連付けはサポートされていません。
Fusion Middleware Controlによって、匿名SSL接続をサポートするために必要な権限が追加されて、ファイルweblogic.policyが変更されます。
「接続DN」テキスト・ボックスに、1から256文字の文字列で完全な識別名を入力します。たとえば、cn=orcladmin、dc=us、dc=oracle、dc=comです。
「パスワード」ボックスに、1から256文字を含む文字列であるユーザー・パスワードを入力します。
入力したデータを使用したLDAPサーバーへの接続が機能することを確認するには、「LDAP認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第L.9項「匿名SSL接続の確立の失敗」を参照してください。
「ルート・ノードの詳細」領域で、「ルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。
この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第L.2項「再関連付けの失敗」を参照してください。
必要に応じて「ポリシー・ストアのプロパティ」領域と「資格証明ストアのプロパティ」領域に、「遅延ロードの有効化」や「ロール・メンバーのキャッシュ・サイズ」などのサービス・インスタンスのプロパティを入力します。
新規のプロパティを追加するには、「追加」をクリックし、「新規プロパティの追加」ダイアログ・ボックスで「プロパティ名」と「値」に文字列を入力して、「OK」をクリックします。追加されたプロパティと値のペアが、表「カスタム・プロパティ」に表示されます。
これらのプロパティは通常、インスタンスの作成時にインスタンスを初期化するために使用されます。
ドメイン構成ファイルjps-config.xmlにあるLDAPサービス・インスタンスの構成に、入力したプロパティと値を指定した<property>要素が追加されて、この構成ファイルが変更されます。
サービス・インスタンスの変更例として、プロパティ名fooと値barを入力したとします。この場合は、次に示すような<property>要素が追加され、LDAPサービス・インスタンスの構成が変更されます。
<serviceInstance name="myNewLDAPprovider" provider="someProvider" ... <property name="foo" value="bar"/> ... </serviceInstance>
データの入力を完了したら、「OK」をクリックし、「セキュリティ・プロバイダ構成」ページに戻ります。再関連付けのステータスを示すダイアログ・ボックスが表示されます。「セキュリティ・ストア」領域の表が変更されて、指定したプロバイダが表示されます。
アプリケーション・サーバーを再起動します。サーバーが再起動するまで、変更は有効になりません。
再関連付けによって、ドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成がすべて削除され、新しいストア・プロバイダの構成が追加されます。それにより、ポリシーと資格証明に関する情報が移行元ストアから移行先ストアに移動します。
移行先ストアがLDAPベースの場合、これらの情報は次の形式に従ってドメインDNの下位に保存されます。
cn=<domain_name>,cn=JpsContext,<JPS ROOT DN>
インストールの構成が上位のドメインDNに依存しているかぎり、その上位ドメインのノードはLDAPサーバーから削除しないでください。
この項で説明する手順は必要に応じて実行するものであり、Oracle Internet Directoryにアクセスするときのセキュリティを強化することのみを目的としています。
アクセス制御リスト(ACL)とは、情報にアクセスできるユーザーとOracle Internet Directoryディレクトリ・オブジェクトに対して許可される操作を指定したリストです。この制御リストはノードで指定し、そのノードのすべてのサブツリーにあるすべてのエントリに、リストで指定した制限が適用されます。
ACLを使用して、LDAP Oracle Internet Directoryリポジトリに格納されているポリシー・データおよび資格証明データへのアクセスを制御できます。ACLは通常、ストアの最上位のルート・ノードで指定します。
Oracle Internet DirectoryリポジトリのノードでACLを指定する手順は、次のとおりです。
ACLを指定する内容を記述したLDIFファイルを作成します。
dn: <storeRootDN> changetype: modify add: orclACI access to entry by dn="<userDN>" (browse,add,delete) by * (none) access to attr=(*) by dn="<userDN>" (search,read,write,compare) by * (none)
storeRootDNはノード(通常はストアのルート・ノード)を表し、userDNは管理者データのDN(再関連付けを実行する際に入力したuserDN)を表します。
Oracle Internet Directoryのユーティリティldapmodifyを使用して、これらの指定をOracle Internet Directoryに適用します。
ACLを指定するLDIFファイルの例を次に示します。
dn: cn=jpsRootNode changetype: modify add: orclACI access to entry by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (browse,add,delete) by * ( none ) access to attr=(*) by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (search,read,write,compare) by * (none)
アクセス制御リストおよびldapmodifyコマンドの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の第18章を参照してください。
OPSSストアは、OPSSスクリプトreassociateSecurityStoreを使用して再関連付けできます。詳細は、第9.3.30項「reassociateSecurityStore」を参照してください。
1つのドメインに設定できるポリシー・ストアは1つのみです。アプリケーションで独自のポリシーを指定することができ、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはポリシー・ストアの該当するストライプのアプリケーション・ポリシーとして格納されます。ドメインにデプロイまたは再デプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるドメイン・ポリシー・ストアを使用します。ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。
OPSSセキュリティ・ストアの移行とは、ポリシー、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第L.22項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。
アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。
ポリシー・ストアの構成は、管理者が行います。
この章の内容は次のとおりです。
アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。
アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。
詳細は、第6.6.2項「ポリシーおよび資格証明の移行」の手順を参照してください。
アプリケーション固有のポリシー、システム・ポリシーまたは資格証明は、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。
このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
|
注意: スクリプト |
OPSSスクリプトとその構文の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドのカテゴリの概要に関する項を参照してください。
OPSSスクリプトを実行するためのプラットフォーム固有の要件については、第9.3項「OPSSスクリプトによるアプリケーション・ポリシーの管理」を参照してください。使用方法の詳細は、「使用例」を参照してください。
WebLogicのすべてのポリシー(すべてのアプリケーションのシステム・ポリシーとアプリケーション固有のポリシー)を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")
引数(すべて必須)の意味は、次のとおりです。
configFileでは、構成ファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の要素を含める必要があります。
移行元ストアを指定するコンテキスト
移行先ストアを指定するコンテキスト
ブートストラップ資格証明を指定するコンテキスト
ブートストラップ・コンテキストでは、cwallet.ssoファイルの位置が参照されます。このファイルでは、移行元および移行先のストアへのアクセスおよびそこに含まれるセキュリティ・データの復号化と暗号化に必要なキーが指定されていることが想定されます。
ドメインで使用されるキーの抽出の詳細は、第10.5.6項「exportEncryptionKey」を参照してください。ウォレットへのキーの格納の詳細は、第10.5.7項「importEncryptionKey」を参照してください。
ウォレットの作成の詳細は、『Oracle Fusion Middleware管理者ガイド』のウォレットの一般的な操作に関する項を参照してください。
srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。
dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
WebLogicのシステム・ポリシーのみを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type globalPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
migrateSecurityStore(type="globalPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")
引数(すべて必須)の意味は、前述の場合と同じです。
WebLogicのアプリケーション固有のポリシーのみを移行するには、アプリケーションごとに、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type appPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
-srcApp srcAppName
[-dstApp dstAppName]
[-overWrite trueOrfalse]
[migrateIdStoreMapping trueOrfalse]
[mode laxOrstrict]
migrateSecurityStore(type="appPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", srcApp="srcAppName", [dstApp="dstAppName"], [overWrite="trueOrfalse"], [migrateIdStoreMapping="trueOrfalse"], [mode="strict"])
configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。その他の5つの引数の意味は次のとおりです。
srcAppでは、ソース・アプリケーションの名前、つまり、ポリシーを移行するアプリケーションの名前を指定します。
dstAppでは、ターゲット・アプリケーションの名前、つまり、ポリシーを書き込むアプリケーションの名前を指定します。指定しない場合は、デフォルトでソース・アプリケーションの名前になります。
migrateIdStoreMappingでは、エンタープライズ・ポリシーを移行するかどうかを指定します。デフォルト値はTrueです。エンタープライズ・ポリシーを移行の対象から除外する場合、つまりアプリケーション・ポリシーのみを移行する場合は、Falseに設定します。
overWriteでは、ソース・ポリシーと一致するターゲット・ポリシーをソース・ポリシーで上書きするか、ソース・ポリシーとマージするかを指定します。ターゲット・ポリシーを上書きする場合はTrueに設定し、一致するポリシーをマージする場合はFalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。
modeでは、移行を停止して、アプリケーション・ポリシーでプリンシパルまたはパーミッションが重複していることを示すエラーを送信するかどうかを指定します。何も指定しないか、LAXに設定します。LAXに設定すると、重複項目があっても移行が継続して、重複項目のいずれかのみが移行し、この効果に対する警告がログに記録されます。
前述の構文要件に一致しない入力を指定すると、スクリプトの実行に失敗し、エラーが返されます。特に、入力は次の要件を満たす必要があります: (a) 渡された位置内でファイルjps-config.xmlが検出される; (b) 渡されたjps-contextsがファイルjps-config.xmlに含まれている; (c) ソースおよびターゲットのコンテキスト名が一意。
すべての資格証明を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type credStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
migrateSecurityStore(type="credStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")
configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。
1つの資格証明マップのみを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type folderCred
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-srcFolder map1]
[-dstFolder map2]
[-srcConfigFile alternConfigFileLocation]
[-overWrite trueOrFalse]
migrateSecurityStore(type="folderCred", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [srcFolder="map1"],
[dstFolder="map2"], [srcConfigFile="alternConfigFileLocation"], [overWrite="trueOrFalse"])
configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。最後の4つの引数(すべてオプション)の意味は次のとおりです。
srcFolderでは、移行する資格証明を収めたマップの名前を指定します。オプション。指定しない場合、資格証明ストアにはマップが1つのみであると想定され、この引数の値はデフォルトでそのマップの名前になります。
dstFolderでは、ソース資格証明の移行先のマップを指定します。この引数はオプションで、指定されない場合、srcFolderに渡されるマップがデフォルトになります。
srcConfigFileでは、代替構成ファイルの場所を指定します。これは、configFileに渡されるファイルで資格証明が構成されていないという特別な場合に使用されます。この引数はオプションで、指定しない場合、デフォルトでconfigFileに渡される値になります。指定した場合、configFileに渡される値は無視されます。
overWriteでは、ソース資格証明と一致するターゲット資格証明をソース資格証明で上書きするか、ソース資格証明とマージするかを指定します。ターゲット資格証明を上書きする場合はTrueに設定し、一致する資格証明をマージする場合はFalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。Falseに設定した場合、一致する資格証明が検出されると、ソース資格証明は無視され、警告がログに記録されます。
スクリプトmigrateSecurityStoreを使用して、監査メタデータをドメイン・セキュリティ・ストアに移行するか、監査メタデータをXMLファイルに移行できます。
詳細は6.6.3項を参照してください。
このスクリプトの使用を示している完全な例は、次の各項を参照してください。
この項では、Fusion Middleware Controlを使用して、いくつかのサービス・プロバイダを構成する方法を説明します。この項の内容は次のとおりです。
ポリシー、資格証明、キーおよび監査を構成するには、次の各項を参照してください。
アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータを構成する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて、「アイデンティティ・ストア・プロバイダ」領域を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。
必要に応じて、「追加」ボタンと「削除」ボタンを使用してカスタム・プロパティを管理します。
完了したら、「OK」をクリックして設定を保存し、「セキュリティ・プロバイダ構成」ページに戻ります。
ドメインで使用するSSOプロバイダを構成するには、次の手順を実行します。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
そのページで、「シングル・サインオン・プロバイダ」領域の「構成」をクリックして、「シングル・サインオン・プロバイダ」ページを表示します。
そのページで、「シングル・サインオン・プロバイダ」ボックスを選択して、プロバイダのデータを入力できるようにします。このボックスを選択するまで、すべてのボックスはグレー表示になっています。
プルダウン・リストから「ストア・タイプ」を選択し、選択したプロバイダに該当するデータを入力します(必要なデータは、選択したタイプによって異なります)。
「ログインURL」、「自動ログインURL」および「ログアウトURL」をそれぞれのテキスト・ボックスに入力します。
プルダウン・リストから「認証レベル」を選択します。
必要に応じ、ページの下部にある「追加」、「編集」および「削除」を使用してプロバイダの「カスタム・プロパティ」を管理します。
完了したら、「OK」をクリックして、入力したデータを保存します。
ドメインで使用するトラスト・サービス・プロバイダを構成するには、次の手順を実行します。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
このページの「トラスト・サービス・プロバイダ」領域には、トラスト・サービスが構成されているかどうかが示されます。トラスト・サービスを構成するには、「構成」をクリックして、「トラスト・サービス・プロバイダ」ページを表示します。
このページには次の領域が含まれています。
プロバイダ: 選択したプロバイダの名前が表示されます。
トラスト・ストア: 表示される選択肢からストライプおよびトラスト・ストアを選択します。
キーストアと別名: ストライプとキーストアを選択することによって証明書を選択し、使用可能なトラスト別名のリストから別名を選択します。この領域の下部にある読取り専用のエントリ(「発行者名」および「有効期限」)には、選択した証明書に関する情報が表示されます。
トラスト・サービス構成: 次の値を入力します。
時間誤差: (トラスト・サービスの使用に関連している)2つのシステムのクロック間で許容される誤差を秒数で指定します。デフォルトは60です。
トークンの有効期間: トークンの有効期間を秒数で指定します。デフォルトは1800です。
証明書を含める: 証明書をトークンに含める必要があるかどうかをブール値で指定します。
コードソース権限: クライアント・コード(対象のトラスト・ストアにアクセスする)のURLを指定します。デフォルト値はありません。この情報は、指定されたコードに付与されるコードソース権限に変換されます。
「OK」をクリックして、入力したデータを保存し、「セキュリティ・プロバイダ構成」ページに戻ります。入力した値は、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlに保存されます。
プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。
OPSS構成プロパティのリストは、付録F「OPSS構成プロパティ」を参照してください。
プロパティおよびプロパティ・セットの定義には、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlで<property>要素と<properySet>要素を使用します。プロパティ・セットは、<propertySetRef>要素で参照できます。
プロパティまたはプロパティ・セットを定義する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて、「拡張プロパティ」領域を開き、「構成」をクリックして「拡張プロパティ」ページを表示します。
プロパティを入力するには、「プロパティ」領域の「追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。完了したら、「OK」をクリックします。入力したプロパティが「プロパティ」の表に表示されます。
プロパティ・セットを入力するには、「プロパティ・セット」領域の「プロパティ・セットの追加」をクリックして「プロパティ・セットの追加」ダイアログ・ボックスを表示し、プロパティ・セット名を入力します。
プロパティ・セットにプロパティを入力するには、既存のプロパティ・セットを選択し、「プロパティの追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。入力したプロパティが、選択したプロパティ・セットのプロパティのリストに追加されます。
どの表でも、選択した項目をその表から削除するには、「削除」ボタンを使用します。プロパティおよびプロパティ・セットの入力または編集が完了したら、「OK」をクリックします。
Oracle WebLogic Serverを再起動します。サーバーが再起動するまで、変更は有効になりません。
プロパティ・セットを追加または削除するとドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されますが、サーバーを再起動しないかぎり、その変更は有効になりません。
前述の手順で追加した<property>要素と<propertySet>要素は、<jpsConfig>要素の直下に挿入されます。
