Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.2) E47967-02 |
|
![]() 前 |
![]() 次 |
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セキュリティ・ストアは、本番WebLogicドメイン用にDBベースになっています。
Java EEアプリケーションに関するセキュリティ・アーティファクトは、通常、アプリケーションとともにパッケージされているため、デプロイ時にOPSSセキュリティ・ストアに移行できます。OPSSセキュリティ・ストアへの移行に使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した移行およびスクリプトmigrateSecurityStoreを使用した移行の項を参照してください。
複数のサーバー・インスタンス(管理サーバーおよび管理対象サーバー)が同じホスト上にあるか複数のマシンに分散されている本番WebLogicドメインでは、OIDベースまたはOracle RDBMSベースのOPSSセキュリティ・ストアを使用する必要があります。
注意: 本番環境ではファイルベースのプロバイダは推奨されません。 |
ポリシーおよび資格証明に設定可能なプロパティの詳細は、付録F「ポリシー・ストアのプロパティ」および付録F「資格証明ストアのプロパティ」を参照してください。
LDAPベースのOPSSセキュリティ・ストアは、通常、本番環境で使用します。サポートされている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ベースのすべてのインスタンスに共通するプロパティ」を参照してください。
LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directoryのみです。Oracle Internet Directoryに正しくアクセスできるようにするには、後述する手順で、ノードをサーバー・ディレクトリに設定する必要があります。
Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.sso
に自動的に設定されます。これらの必要な資格証明を手動で指定する場合は、第18.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セキュリティ・ストアの再関連付けを行う場合は、「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の設定
アイデンティティ・ストア・サービスとOPSSセキュリティ・ストア・サービスでは、使用するソケット・ファクトリが異なるため、次の手順も異なります。
サーバーとアイデンティティ・ストア間で一方向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>
サーバーとOPSSセキュリティ・ストア間で一方向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アプリケーションの場合、設定はアイデンティティ・ストアとOPSSセキュリティ・ストアの両方で同じです。
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またはWLSTコマンドを使用し、その資格証明ストアを構成する必要があります。サーバーが初期化を完了する前に任意のチェックが必要な場合は、第J.3.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);
DBベースのOPSSセキュリティ・ストアへの一方向または双方向SSL接続の確立はオプションであり、詳細は『Oracle Fusion Middlewareの管理』のデータベースでのSSLの構成に関する説明を参照してください。
SSL関連のトピックの補足情報は、次のドキュメントを参照してください。
Oracle Database JDBC開発者ガイド
Java SEアプリケーション用のストア構成の例は、第20.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストア」を参照してください。
Java EEアプリケーション用のストア構成の例は、例1を参照してください。
その他のアーティファクトの構成の詳細は、「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。
OPSSセキュリティ・ストアの再関連付けとは、セキュリティ・アーティファクトをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみがサポートされ、DBタイプのターゲットでは、Oracle Databaseのみがサポートされています。
再関連付けでは、格納データの整合性を保持しながらリポジトリが変更されます。すべてのセキュリティ・アーティファクトが、既存のセキュリティ・ストアから新しいターゲット・ストアに移行されます。この操作は、ドメインの作成後であればいつでも行うことができ、次の項で説明されているように、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
およびjps-config-jse.xml
が適切な新しい構成で更新されます。
Fusion Middleware Controlを使用してOPSSセキュリティ・ストアを再関連付けする手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します(次の図にページの一部を示します)。
「セキュリティ・ストア」領域の表には、現在ドメインで構成されているプロバイダの特性が表示されます。
「アソシエーションの変更」ボタンをクリックして、「セキュリティ・プロバイダの設定」ページを表示し、プルダウン・リストから「ストア・タイプ」を選択します。このページに表示されるテキストは、選択したストア・タイプによって異なります。次の図に、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認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第J.5.5項「匿名SSL接続の確立の失敗」を参照してください。
「ルート・ノードの詳細」領域で、「ルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。
この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第J.2.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章を参照してください。
OPSSストアの再関連付けは、WLSTコマンドreassociateSecurityStore
を使用して行うことができます。詳細は、第10.3.1項「reassociateSecurityStore」を参照してください。
ドメインには、セキュリティ・ストアが1つのみ含まれます。アプリケーションで独自のポリシーを指定することができ、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはセキュリティ・ストアの該当するストライプのアプリケーション・ポリシーとして格納されます。ドメインにデプロイまたは再デプロイされたすべてのアプリケーションは、共通のセキュリティ・ストアであるドメイン・セキュリティ・ストアを使用します。このストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml
の<applications>
要素で指定したアプリケーション名ごとにストライプが1つずつあります。
OPSSセキュリティ・ストアの移行とは、ポリシー、資格証明、監査メタデータおよびキーをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのOPSSセキュリティ・ストアには、互換性のあるバージョンを使用する必要があります(詳細は、第J.8.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください)。
アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。
OPSSセキュリティ・ストアの構成は、管理者によって実行されます。
この章の内容は次のとおりです。
注意: WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティ このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイル |
アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xml
で指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにOPSSセキュリティ・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにOPSSセキュリティ・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。
アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。
詳細は、第6.6.2項「ポリシーおよび資格証明の移行」の手順を参照してください。
アプリケーション固有のポリシー、システム・ポリシーまたは資格証明は、WLSTコマンドmigrateSecurityStore
を使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。
このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFile
で渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
注意: スクリプト |
WLSTコマンドを実行するためのプラットフォーム固有の要件については、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。使用方法の詳細は、「使用例」を参照してください。
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
ファイルの位置が参照されます。このファイルでは、移行元および移行先のストアへのアクセスおよびそこに含まれるセキュリティ・データの復号化と暗号化に必要なキーが指定されていることが想定されます。
ドメインで使用されるキーの抽出の詳細は「exportEncryptionKey」を、ウォレットへのキーの格納の詳細は「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を使用して、いくつかのサービス・プロバイダを構成する方法を説明します。この項の内容は次のとおりです。
注意: 「セキュリティ・プロバイダ構成」ページの「Web Services Managerの認証プロバイダ」領域は、Web Services Managerのログイン・モジュールとキーストアの構成にのみ関連し、ADFアプリケーションとJava EEアプリケーションには関連しません。 |
ポリシー、資格証明、キーおよび監査を構成するには、次の各項を参照してください。
アイデンティティ・ストアと対話するユーザー/ロール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>
要素の直下に挿入されます。