| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 11gリリース1 (11.1.1) E64849-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 11gリリース1 (11.1.1) E64849-03 |
|
前 |
次 |
OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、キーおよび監査メタデータが格納されるリポジトリです。
この章では、OPSSセキュリティ・ストアの機能について、次の各項で説明します。
Java EEおよびWebLogicのセキュリティの詳細は、『Oracle WebLogic Serverセキュリティの理解』のJava EEおよびWebLogicのセキュリティに関する説明を参照してください。
|
注意: この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。 |
|
重要: OPSSセキュリティ・ストアのポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。 |
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を使用した移行の項を参照してください。
複数のサーバー・インスタンス(管理サーバーおよび管理対象サーバー)が同じホスト上にあるか複数のマシンに分散されている本番WebLogicドメインでは、OIDベースまたはOracle RDBMSベースのOPSSセキュリティ・ストアを使用する必要があります。
|
注意: 本番環境ではファイルベースのプロバイダは推奨されません。 |
|
重要事項: JRFテンプレートによって作成または拡張されたドメインでは、そのすべてのリソースが管理サーバーにのみターゲット指定されます。後で管理対象サーバーをドメインに追加するときは、applyJRFユーティリティを起動して、リソースが管理対象サーバーにもターゲット指定されるようにする必要があります。つまり、ドメイン再構成後のOPSSと監査データ・ソースを管理対象サーバーにターゲット指定するには、applyJRFを次の形式で実行する必要があります。
applyJRF('managedServer1', '<domain_dir>')
|
ポリシーおよび資格証明に設定できるプロパティの詳細は、付録F「OPSSのシステムおよび構成プロパティ」を参照してください。
前述したように、製品環境の推奨は集中管理されたOIDベースまたはDBベースのストアを使用することです。
ファイル・ベースのセキュリティ・ストアの環境では、次の点について注意します。
管理サーバー(cwallet.sso、audit-store.xml、system-jazn-data.xml、keystores.xml)にあるリポジトリ・ファイルが真実のソースです。
ストアに対する変更はすべて、ドメイン全体で一貫性を保つために管理サーバーで実行する必要があります。
管理サーバーから管理対象サーバーへのリポジトリ・ファイルのレプリケーションは、管理サーバーが再起動されたとき、またはJMXフレームワークが実行時に変更を検出したときに実行されます。
OPSSでは、リポジトリ・ファイルがファイル・ロッキングをサポートするファイル・システムに配置される必要があります。第K.4.4項「サーバーの起動の失敗」を参照してください。
LDAPベースのポリシー・ストアは、通常、本番環境で使用します。今回のリリースでサポートされているLDAPサーバーは、Oracle Internet Directory(リリース10.1.4.3以降)のみです。
|
注意: バージョンに応じて、次のパッチをOracle Internet Directoryに適用する必要があります。
パッチを適用するには、次のようにします。
|
ドメインでLDAPベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用し、その資格証明ストアを構成する必要があります。
|
重要: OPSSは、Oracle Internet Directoryサーバーでの参照整合性の有効化をサポートしていません。参照整合性を有効化した場合、サーバーは想定したとおりには機能しません。サーバーの参照整合性を無効にするには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにします。
|
サービス・インスタンスで指定できるプロパティのリストは、付録F「共通プロパティ」を参照してください。
LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directoryのみです。Oracle Internet Directoryに正しくアクセスできるようにするには、後述する手順で、ノードをサーバー・ディレクトリに設定する必要があります。
Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。これらの必要な資格証明を手動で指定する場合は、第23.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サーバーの構成
Oracle Internet Directoryサーバーが一方向SSLモードでリスニングするように構成するには、『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のみです。
サポートされているバージョンについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlにある「Oracle Fusion Middleware Supported System Configurations」を参照してください。
動作保証情報は、http://www.oracle.com/technetwork/middleware/downloads/fmw-11gr1certmatrix.xlsの動作保証マトリックスを参照してください。
|
注意: 開発環境でのみ、OPSSセキュリティ・ストアとして、Oracle RDBMS Express、Oracle RDBMS Standard EditionおよびOracle RDBMS Standard Edition Oneを使用できます。 |
DBベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用し、その資格証明ストアを構成する必要があります。サーバーが初期化を完了する前になんらかのチェックが必要な場合は、第K.4.6項「サーバーの起動前のパーミッション・チェックの失敗」を参照してください。OPSSスキーマおよび監査スキーマの両方で、エディション・ベースの再定義(EBR)がサポートされます。
構成可能なプロパティの一覧は、付録F「OPSSのシステムおよび構成プロパティ」を参照してください。
この項には次のトピックが含まれます:
OPSSセキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。
このタスクの詳細は、『Repository Creation Utilityによるスキーマの作成』の付録A「Repository Creation Utilityの各画面の理解」を参照してください。OPSSスキーマを作成するには、次のスキーマを選択します。
<prefix>_OPSS
<prefix>_IAU
<prefix>_IAU_APPEND
<prefix>_IAU_VIEWER
この項では、管理者が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のセットアップ中に作成された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);
OPSSスキーマのパスワードをリセットするには、次の手順を実行します。
DBコマンドALTER USERを使用して、DBのパスワードをリセットします。次の2つの手順で使用しますので、入力した新しいパスワードを忘れないでください。
Oracle WebLogic管理コンソールを使用して、ドメインのデータ・ソースがOPSSスキーマへの接続に使用しているパスワードを新しいパスワードで更新します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』を参照してください。『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』
WLSTコマンドmodifyBootStrapCredentialを使用し、新しいパスワードでブートストラップ・ウォレットを更新します。詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
DBベースのOPSSセキュリティ・ストアへの一方向または双方向SSL接続の確立はオプションであり、詳細は『Oracle Fusion Middlewareの管理』のデータベースでのSSLの構成に関する項の説明を参照してください。
SSL関連のトピックの補足情報は、次のドキュメントを参照してください。
Oracle Database JDBC開発者ガイド
Java SEアプリケーション用のストア構成の例は、第17.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。
その他のアーティファクトの構成の詳細は、「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アプリケーションの場合は、第17.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認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第K.6.5項「匿名SSL接続の確立の失敗」を参照してください。
「ルート・ノードの詳細」領域で、「ルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。
この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第K.3.1項「再関連付けの失敗」を参照してください。
必要に応じて「ポリシー・ストアのプロパティ」領域と「資格証明ストアのプロパティ」領域に、「遅延ロードの有効化」や「ロール・メンバーのキャッシュ・サイズ」などのサービス・インスタンスのプロパティを入力します。
新規のプロパティを追加するには、「追加」をクリックし、「新規プロパティの追加」ダイアログ・ボックスで「プロパティ名」と「値」に文字列を入力して、「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章を参照してください。
コマンドreassociateSecurityStoreは、ソース・ストアからターゲット・ストアにOPSSセキュリティ・ストアを移行し、jps-config.xmlファイルおよびjps-config-jse.xmlファイル内のサービス構成をターゲット・リポジトリにリセットします。
ソース・ストアは、ファイルベース、OIDベースまたはDBベース・ストアのいずれかです。ターゲット・ストアには、まったく新しいストア、または他のドメインにある既存のストア(後述のオプションの引数joinを参照)を使用できます。既存のストアの場合、結合したターゲット・ストアにソース・ストアのデータを追加するかどうかを指定できます(後述のオプションの引数migrateを参照)。
ソース・ストアのバージョンは、ターゲット・ストアのバージョンと同じかまたはそれ以降である必要があります。バージョンが異なる場合(つまり、ソースのバージョンがターゲットのバージョンよりも新しい場合)、コマンドはソースとターゲットのセキュリティ・アーティファクトの間の互換性チェックを行います。アーティファクトのいずれかでチェックがエラーとなった場合、コマンドは互換性のないアーティファクトの移行をスキップできるように、引数skipをtrueに設定します。この引数がtrueに設定されていないときに互換性のないアーティファクトが検出されると、コマンドはそこで終了します。
このコマンドはブートストラップ資格証明をリセットします(後述の引数adminおよびpasswordを参照)。ブートストラップ資格証明をリセットする別の方法については、WLSTコマンドのmodifyBootStrapCredentialとaddBootStrapCredentialを参照してください。
再関連付けに関連する推奨事項は、「重要ポイント」を参照してください。このコマンドは、インタラクティブ・モードでのみサポートされます。
|
注意: 指定されたドメインと、指定されたメジャー・リリース(11gまたは12c)で、OPSSバイナリのバージョンはOPSSセキュリティ・ストアのバージョンと同じか、またはそれ以降である必要があります。第K.9.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。 |
インタラクティブ・モード構文
コマンド構文は、ターゲット・ストアのタイプに応じて若干異なります。ターゲットがOIDベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。
reassociateSecurityStore(domain="domainName",
servertype="OID",
ldapurl="hostAndPort",
jpsroot="cnSpecification",
admin="cnSpecification",
password="passWord",
[join="trueOrfalse"] [,keyFilePath="dirLoc", keyFilePassword="password"]]
[migrate="trueOrfalse"]
[skip="trueOrfalse"]
[force="trueOrfalse"])
ターゲットがDBベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。
reassociateSecurityStore(domain="domainName",
servertype="DB_ORACLE",
datasourcename="datasourceName",
jpsroot="jpsRoot",
jdbcurl="jdbcURL",
jdbcdriver="jdbcDriverClass",
dbUser="dbUserName",
dbPassword="dbPassword",
[admin="adminAccnt", password="passWord",]
[,join="trueOrfalse"
[,keyFilePath="dirLoc", keyFilePassword="password"] [,migrate="trueOrfalse" [,skip="trueOrfalse"]]])
[odbcdsn="odbcDsnSting"]
[migrate="trueOrfalse"]
[skip="trueOrfalse"]
[force="trueOrfalse"])
次に、引数join、migateおよびskipの使用に関する要点をまとめます。
引数migrateはjoinがtrueに設定されている場合のみ使用され、それ以外の場合は無視されます。つまり、移行が必要である場合は、joinとmigrateの両方をtrueに設定する必要があります。
joinとmigrateが両方ともtrueに設定されている場合、引数keyFilePathとkeyFilePasswordは必須です。
joinとmigrateの両方がtrueに設定されているときに、skipがtrueの場合、ターゲット・ストアと互換性のないアーティファクトの移行はスキップされます。skipがfalse(デフォルト値)の場合、互換性のないアーティファクトが検出されるとコマンドはそこで終了します。このリリースでは、汎用資格証明のみ、スキップがサポートされています。
引数の意味は、次のとおりです。
domain: WebLogicでは、ターゲット・ストアが配置されているドメイン名を指定します。サーバー・タイプがDB_ORACLEの場合はオプションです。
adminでは、LDAPターゲットの場合、ターゲット・サーバーに対する管理者のユーザー名を指定します。形式はcn=usrNameです。
DBターゲットの場合は、DBに保護データ・ソースがある(つまり、ユーザー/パスワードで保護されている)場合にのみ必要です。この場合、データ・ソースが作成されたときにデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。指定した場合は、passwordも指定する必要があります。
passwordでは、引数adminに対して指定したユーザーと関連付けられたパスワードを指定します。OIDターゲットの場合にのみ必要です。
DBターゲットの場合は、DBに保護データ・ソースがある場合にのみ必要で、当該の場合は引数adminで指定されたユーザーに関連付けられたパスワードを指定します。指定した場合は、adminも指定する必要があります。
ldapurlでは、OIDサーバーのURIを指定します。デフォルトのポートを使用する場合の形式は、ldap://host:portです。匿名SSLまたは一方向SSL伝送を使用する場合の形式は、ldaps://host:portです。目的のSSL接続モードを扱うことができるようにセキュア・ポートを構成する必要があります。また、このセキュア・ポートは、デフォルトの(セキュアではない)ポートとは別のポートとする必要があります。
servertypeでは、ターゲット・ストアの種類を指定します。有効なタイプは、OIDまたはDB_ORACLEのみです。
jpsrootでは、ターゲットOIDリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。サーバー・タイプがDB_ORACLEの場合はオプションです。
joinでは、ターゲット・ストアが他のドメインにある既存のストアであるかどうかを指定します。オプション。他のドメインにある既存のターゲット・ストアを共有する場合はtrueに設定します。それ以外の場合はfalseに設定します。指定しなかった場合は、デフォルトでfalseに設定されます。この引数を使用することにより、複数のWebLogicドメインから同一の論理OPSSセキュリティ・ストアを指定できるようになります。
|
注意1: joinにtrueを指定して、OPSSセキュリティ・ストアを別のドメインに再度関連付ける場合、OPSS暗号化鍵を一方のドメインからエクスポートして、他方のドメインにインポートする必要があります。
この注意では、このタスクの実行方法について説明しています(別の方法については、引数 たとえば、Domain1にセキュリティ・ストアがあるときに、
キーのインポートやエキスポートに使用するコマンドの詳細は、exportEncrytionKeyとimportEncryptionKeyを参照してください。 |
migrateはjoinがtrueに設定されている場合のみ有効で、それ以外の場合は無視されます。migrateは結合したストアにソース・ストア内のデータを追加するかどうかを表します。ソース・データをターゲット・ストアに追加する場合はtrue、ソース・データを追加せずにターゲット・ストアに結合する場合はfalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。
skipはjoinとmigrateの両方がtrueに設定されている場合のみ有効で、それ以外の場合は無視されます。skipは互換性のないアーティファクトの移行をスキップするかどうかを表します。互換性のないアーティファクトをターゲット・ストアに追加し、コマンドの実行をそのまま続ける場合はtrue、ソース・ストアで互換性のないアーティファクトを検出したときにコマンドを終了する場合はfalseに設定します。オプション。指定しなかった場合は、デフォルトでfalseに設定されます。
datasourcenameでは、JDBCデータ・ソースのJNDI名を指定します。これはデータ・ソース作成時に入力されたJNDI名データ・ソースの値と同じである必要があります。
keyFilePathでは、ターゲット・ドメインのewallet.p12ファイルの配置先ディレクトリを指定します。このファイルの内容は、keyFilePasswordに渡される値により暗号化され、保護されます。joinがtrueに設定されている場合のみ必須です。
|
注意2: joinにtrueを指定して、OPSSセキュリティ・ストアを別のドメインに再度関連付ける場合、OPSS暗号化鍵を一方のドメインからエクスポートして、他方のドメインにインポートする必要があります。
この注意では、このタスクの実行方法について説明しています(別の方法については、引数 引数 たとえば、Domain1にセキュリティ・ストアがあるときに、
|
keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。joinがtrueに設定されている場合のみ必須です。
jdbcurlでは、Java SEアプリケーションでデータベースへの接続に使用するJDBC URLを指定します。Java SEアプリケーションにのみ適用されます。必須。引数jdbcdriver、dbUserおよびdbPasswordとともに使用する必要があります。
jdbcdriverでは、データベースへの接続に使用するJDBCドライバのクラスを指定します。必須。引数jdbcurlとともに使用する必要があります。
dbUserでは、ブートストラップ資格証明に追加する資格証明ストア内のデータベース・ユーザーを指定します。必須。引数jdbcurlとともに使用する必要があります。
dbPasswordでは、dbUserを使用して指定したユーザーのパスワードを指定します。必須。引数jdbcurlとともに使用する必要があります。
odbcdsnでは、C CSF APIで使用するODBC DSN名を指定します。Cプログラムにのみ適用されます。
forceでは、データ移行が開始される前にセキュリティ・ストアを削除するかどうかを指定します。オプションで、デフォルトはfalseです。trueに設定されている場合、既存のセキュリティ・ストアおよびjpsrootパラメータおよびdomainパラメータで指定されたデータが最初に削除されます。joinパラメータをfalseに設定する必要があり、falseに設定されていない場合、この引数は無視されます。joinがfalseに設定され、forceがtrueに設定されている場合、コマンドはセキュリティ・ストア・クリーン・アップの開始と終了を指定するメッセージを出力します。
使用例
次のコードは、DBベースのセキュリティ・ストアを再度関連付けるための呼出しの例です。
reassociateSecurityStore(domain="farm", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="jdbc/opssds", jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb", dbUser="test_opss", dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", force="true")
ソース・セキュリティ・ストアの内容を移行せずにotherDomain内のOPSSセキュリティ・ストアを共有するには、次の例のようにコマンドを呼出します。
reassociateSecurityStore(domain="otherDomain", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="jdbc/opssds", jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",dbUser="test_opss", dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", join="true", keyFilePath="/tmp/myFileDirectory", keyFilePassword="password")
otherDomain内のOPSSセキュリティ・ストアを共有し、互換性のないアーティファクトをスキップしながら、ソース・セキュリティ・ストアの内容をDBベースのターゲット・セキュリティ・ストアに移行するには、次の例のようにコマンドを呼出します。
reassociateSecurityStore(domain="otherDomain", servertype="DB_ORACLE", jpsroot="cn=jpsroot", datasourcename="jdbc/opssds", jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",dbUser="test_opss", dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", join="true", migrate="true", skip="true", keyFilePath="/tmp/myFileDirectory", keyFilePassword="password")
アプリケーションで独自のポリシーを指定することができ、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはポリシー・ストアの該当するストライプのアプリケーション・ポリシーとして格納されます。ドメインにデプロイまたは再デプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるドメイン・ポリシー・ストアを使用します。ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。
セキュリティ・ストアの移行とは、ポリシー、資格証明およびキー・ストアをリポジトリ間で再配置するプロセスです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第K.9.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。
アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。
OPSSセキュリティ・ストアの構成は、管理者によって実行されます。
この章の内容は次のとおりです。
|
注意: WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティjps.deployment.handler.disabledを使用します。
このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイル |
アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。
アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。
詳細は、第6.6.2項「ポリシーおよび資格証明の移行」の手順を参照してください。
アプリケーション固有のポリシー、システム・ポリシーまたは資格証明は、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。
このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
|
注意: スクリプトmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、別の手順によるストアの移行を検討することをお薦めします。詳細は、第G.3項「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。 |
WLSTコマンドを実行するためのプラットフォーム固有の要件については、第9.4項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。使用方法の詳細は、「使用例」を参照してください。
WebLogicのすべてのポリシー(すべてのアプリケーションのシステム・ポリシーとアプリケーション固有のポリシー)を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-skip trueOrfalse]
[-overwrite trueOrfalse]
migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext" [,skip="trueOrfalse"] [,overwrite="trueOrfalse"])
引数(すべて必須)の意味は、次のとおりです。
configFileでは、構成ファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の要素を含める必要があります。
移行元ストアを指定するコンテキスト
移行先ストアを指定するコンテキスト
ブートストラップ資格証明を指定するコンテキスト
ブートストラップ・コンテキストでは、cwallet.ssoファイルの位置が参照されます。このファイルでは、移行元および移行先のストアへのアクセスおよびそこに含まれるセキュリティ・データの復号化と暗号化に必要なキーが指定されていることが想定されます。
ドメインで使用されるキーの抽出の詳細は「exportEncryptionKey」を、ウォレットへのキーの格納の詳細は「importEncryptionKey」を参照してください。
ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』のウォレットの一般的な操作に関する説明を参照してください。
srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。
dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。
skipは、互換性のないアーティファクトの移行をスキップするか、またはソース・リポジトリで互換性のないアーティファクトを検出した時に終了するかを指定します。互換性のないアーティファクトの移行をスキップするが、終了しない場合はtrue、互換性のないアーティファクトが検出されたときに終了する場合はfalseに設定します。オプションです。指定しない場合は、デフォルトでfalseになります。
overWriteはターゲット・ストア内の既存のデータを上書きするかどうかを指定します。既存の宛先データを上書きする場合はtrue、既存の宛先データを上書きしない場合はfalseに設定します。オプションで、デフォルトはfalseです。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義する必要があります。また、名前は重複していてはいけません。さらに、渡すコンテキストと構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
WebLogicのシステム・ポリシーのみを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type globalPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-overwrite trueOrfalse]
migrateSecurityStore(type="globalPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext" [,overwrite="trueOrfalse"])
引数(すべて必須)の意味は、前述の場合と同じです。
WebLogicのアプリケーション固有のポリシーのみを移行するには、アプリケーションごとに、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type appPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
-srcApp srcAppName
[-dstApp dstAppName]
[-overWrite trueOrfalse]
[-migrateIdStoreMapping trueOrfalse]
[-mode laxOrstrict]
[-skip trueOrfalse]
migrateSecurityStore(type="appPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", srcApp="srcAppName", [dstApp="dstAppName"], [overWrite="trueOrfalse"], [migrateIdStoreMapping="trueOrfalse"], [mode="strict"], skip="trueOrfalse")
引数configFile、src、dstおよびskipの意味は前述の場合とまったく同じです。その他の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
[-skip trueOrfalse]
[-overwrite trueOrfalse]
migrateSecurityStore(type="credStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [skip="trueOrfalse"], [overwrite="trueOrfalse"])
引数configFile、src、dst、skipおよびoverwriteの意味は前述の場合とまったく同じです。
1つの資格証明マップのみを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。
migrateSecurityStore.py -type folderCred
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-srcFolder map1]
[-dstFolder map2]
[-srcConfigFile alternConfigFileLocation]
[-overWrite trueOrFalse]
[-skip trueOrFalse]
migrateSecurityStore(type="folderCred", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [srcFolder="map1"],
[dstFolder="map2"], [srcConfigFile="alternConfigFileLocation"], [overWrite="trueOrFalse"], [skip="trueOrFalse"])
引数configFile、src、dstおよびskipの意味は前述の場合とまったく同じです。最後の4つの引数(すべてオプション)の意味は次のとおりです。
srcFolderでは、移行する資格証明を収めたマップの名前を指定します。オプション。指定しない場合、資格証明ストアにはマップが1つのみであると想定され、この引数の値はデフォルトでそのマップの名前になります。
dstFolderでは、ソース資格証明の移行先のマップを指定します。この引数はオプションで、指定されない場合、srcFolderに渡されるマップがデフォルトになります。
srcConfigFileでは、代替構成ファイルの場所を指定します。これは、configFileに渡されるファイルで資格証明が構成されていないという特別な場合に使用されます。この引数はオプションで、指定しない場合、デフォルトでconfigFileに渡される値になります。指定した場合、configFileに渡される値は無視されます。
overWriteでは、ソース資格証明と一致するターゲット資格証明をソース資格証明で上書きするか、ソース資格証明とマージするかを指定します。ターゲット資格証明を上書きする場合はTrueに設定し、一致する資格証明をマージする場合はFalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。Falseに設定した場合、一致する資格証明が検出されると、ソース資格証明は無視され、警告がログに記録されます。
スクリプトmigrateSecurityStoreを使用して、監査メタデータをドメイン・セキュリティ・ストアに移行するか、監査メタデータをXMLファイルに移行できます。
詳細は6.6.3項を参照してください。
このスクリプトの使用を示している完全な例は、次の各項を参照してください。
この項では、Fusion Middleware Controlを使用して、いくつかのサービス・プロバイダを構成する方法を説明します。この項の内容は次のとおりです。
|
注意: 「セキュリティ・プロバイダ構成」ページの「Web Services Managerの認証プロバイダ」領域は、Web Services Managerのログイン・モジュールとキーストアの構成にのみ関連し、ADFアプリケーションとJava EEアプリケーションには関連しません。使用可能なログイン・モジュールとそのパラメータ、およびそれらのコンポーネントのキー・ストアの詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の第9章を参照してください。 |
ポリシー、資格証明、キーおよび監査を構成するには、次の各項を参照してください。
アイデンティティ・ストアと対話するユーザー/ロール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>要素の直下に挿入されます。
