ヘッダーをスキップ
Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド
11g リリース1(11.1.1)
B56235-06
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

8 OPSSセキュリティ・ストアの構成

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。ポリシー、資格証明、キーおよび証明書の概要は、次の各項を参照してください。

この章では、ポリシー、資格証明およびキーに共通のOPSSセキュリティ・ストアの機能について説明します。この章の内容は次のとおりです。

Java EEおよびWebLogicのセキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のJava EEおよびWebLogicのセキュリティに関する項を参照してください。


注意:

この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。


重要:

OPSSセキュリティ・ストアのポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。

8.1 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を使用した移行の項を参照してください。

8.2 LDAPベースのOPSSセキュリティ・ストアの使用

LDAPベースのポリシー・ストアは、通常、本番環境で使用します。今回のリリースでサポートされているLDAPサーバーは、Oracle Internet Directory(リリース10.1.4.3以降)のみです。


注意:

バージョンに応じて、次のパッチをOracle Internet Directoryに適用する必要があります。

  • Oracle Internet Directory 10.1.4の場合は、Bug 9093298を修正するパッチを適用します。

  • Oracle Internet Directory 11.1.xの場合は、Bug 8736355を修正するパッチを適用します。

  • Oracle Internet Directory 11.1.xおよび10.1.4.3.0の場合は、Bug 8426457を修正するパッチを適用します。

  • Oracle Internet Directory 10.1.4.3.0の場合は、Bug 8351672を修正するパッチを適用します。

パッチを適用するには、次のようにします。

  1. Oracle自動リリース更新にアクセスします。

  2. 「パッチ」タブをクリックします。

  3. 「リクエスト番号」ボックスにバグ番号を入力して、「検索」をクリックします。

  4. パッチを適用します。

ドメインでLDAPベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。


重要:

OPSSは、Oracle Internet Directoryサーバーでの参照整合性の有効化をサポートしていません。参照整合性を有効化した場合、サーバーは想定したとおりには機能しません。

サーバーの参照整合性を無効にするには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにします。

  1. 「管理」を選択してから、「Oracle Internet Directory」メニューの「共有プロパティ」を選択し、「一般」を選択します。

  2. 参照整合性の有効化一覧で、「無効」を選択します。

サービス・インスタンスで指定可能なプロパティの一覧は、付録F「LDAPベースのすべてのインスタンスに共通するプロパティ」を参照してください。

この項の内容は次のとおりです。

8.2.1 複数ノード・サーバー環境

複数のマシンに複数のサーバー・インスタンスが分散されているドメインでは、OPSSセキュリティ・ストアをLDAPベースまたはDBベースにすることを強くお薦めします。

通常、アプリケーションによってポリシー、資格証明、またはキーのデータが変更されることはありません。そのような変更が発生した場合は、それらの変更がドメインにあるすべての管理対象サーバーとクラスタに適切に伝播されることが重要です。したがって、このような変更は、管理対象サーバーではなく、ドメイン管理サーバーで実行することを強くお薦めします。

単一ノード・サーバー・ドメインの場合は、セキュリティ・データのローカル変更の伝播を考慮する必要はありません。このシナリオでは、ローカル変更はグローバル変更と同じです。

ただし、複数ノード・サーバー・ドメインでは、ファイルベースのポリシーに対するローカル変更は、JMXフレームワークによってそれぞれのランタイム環境に伝播されるため、キャッシュ・ポリシーと構成に基づいてデータが更新されます。ポリシーおよび資格証明に設定可能なプロパティの詳細は、付録F「ポリシー・ストアのプロパティ」および付録F「資格証明ストアのプロパティ」を参照してください。

複数ノードのサーバー環境では、ポリシー・ストアおよび資格証明ストアの両方をLDAPベースまたはDBベースのストアで集中管理し、管理サーバーで構成することを強くお薦めします。

8.2.2 LDAPベースのセキュリティ・ストアを使用する場合の前提条件

LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directoryのみです。Oracle Internet Directoryに正しくアクセスできるようにするには、後述する手順で、ノードをサーバー・ディレクトリに設定する必要があります。

Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。これらの必要な資格証明を手動で指定する場合は、第21.4.7項「ブートストラップ資格証明の手動による指定」を参照してください。

Oracle Internet Directoryサーバーのノードの設定

次の手順は、Oracle Internet Directory管理者が実行します。

LDAP Oracle Internet Directoryディレクトリにノードを設定する手順は、次のとおりです。

  1. 次のDNエントリおよびCNエントリを指定するLDIFファイル(ここではjpstestnode.ldifというファイル名にします)を作成します。

    dn: cn=jpsroot
cn: jpsroot
objectclass: top
objectclass: OrclContainer

    ルート・ノードの識別名(前述の例では文字列jpsrootで示す)は、他のどの識別名とも異なる名前にする必要があります。一部のLDAPサーバーでは、デフォルトで大文字小文字が区別されます。1つのルート・ノードを複数のWebLogicドメインで共有できます。このノードは、サブツリーに対する読取りと書込みの権限がOracle Internet Directory管理者に付与されていれば、最上位レベルに作成する必要はありません。

  2. 次の例に示すように、コマンドldapaddを使用してこのデータをLDAPサーバーにインポートします(コマンド呼出し内で改行しないでください)。

    >ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -v -f  jpstestnode.ldif

  3. 次の例に示すように、コマンドldapsearchを使用してノードが正常に挿入されたことを確認します(コマンド呼出し内で改行しないでください)。

    >ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -s base 
-b "cn=jpsroot" objectclass="orclContainer"

  4. 次の例に示すように、ユーティリティoidstats.sqlを実行して、データベースのパフォーマンスを最適にするためにデータベース統計を生成します。

    >$ORACLE_HOME/ldap/admin/oidstats.sql

    このユーティリティは、初期プロビジョニングを行った後に実行する必要があります。このユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。

    ポリシー・ストアの再関連付けを行う場合は、「OPSSセキュリティ・ストアの再関連付け」を参照してください。

8.2.3 LDAPへの一方向SSL接続の設定

この項では、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がある場合は、エクスポートされていることが前提となります)。

  1. 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

  2. サーバーを起動するスクリプト(通常はstartWebLogic.sh)に次のような行を追加して変更し、サーバーを再起動します。

    -Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>

サーバーとポリシー・ストア間で一方向SSL接続を確立する手順は、次のとおりです(信頼できるCAがある場合は、エクスポートされていることが前提となります)。

  1. ユーティリティkeytoolを使用して、次の呼出しのように、信頼できるCAをトラスト・キー・ストアにインポートします。

    >keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword

  2. サーバーを起動するスクリプト(通常はstartWebLogic.sh)に次のような行を追加して変更し、サーバーを再起動します。

    -Dweblogic.security.SSL.trustedCAKeyStore=<absolute path name to file myKeys.jks>

  3. OIDサーバーのSSL証明書でワイルド・カードを使用する場合は、WebLogic Serverを起動するスクリプトに次の行を追加します。

    -Dweblogic.security.SSL.ignoreHostnameVerification=true

Java SEアプリケーションの場合のWebLogic Serverの設定

Java SEアプリケーションの場合、アイデンティティ・ストア・サービスとポリシー・ストア・サービスの設定は同じです。

  1. 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

  2. JMVを起動するスクリプトを変更して、次のような行を追加します。

    -Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>

8.3 DBベースのOPSSセキュリティ・ストアの使用

DBベースのセキュリティ・ストアは、通常、本番環境で使用します。サポートされているDBベースのセキュリティ・ストアは、Oracle RDBMS (リリース10.2.0.4以降、リリース11.1.0.7以降、およびリリース11.2.0.1以降)のみです。

DBベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。サーバーが初期化を完了する前になんらかのチェックが必要な場合は、第L.14項「サーバー起動前のパーミッション・チェックの失敗」を参照してください。

構成可能なプロパティの一覧は、付録F「OPSS構成プロパティ」を参照してください。

この項には次のトピックが含まれます:

8.3.1 DBベースのセキュリティ・ストアを使用する場合の前提条件

OPSSセキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。

RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』の「リポジトリ作成ユーティリティの概要」および「リポジトリ作成ユーティリティの実行」の章を参照してください。

スキーマの作成および初期データのシードについては、次の各項で説明します。

8.3.1.1 OracleデータベースでのOPSSスキーマの作成

RCUを使用して、OracleデータベースにOPSSスキーマを作成する手順は、次のとおりです。

  1. RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの作成」ページを表示します。

  2. そのページで「作成」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。

  3. そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。

    続いて、「次へ」をクリックすると、入力したデータがチェックされ、作成前の操作が実行されます。このチェックが正常に終了すると、「コンポーネントの選択」ダイアログが表示されます。

  4. そのダイアログで、既存スキーマの接頭辞を使用するか、新規の接頭辞を作成するかを選択して、スキーマにインストールするOPSSコンポーネントを選択します。

    コンポーネントを選択したら、「次へ」をクリックして、「スキーマ・パスワード」ダイアログを表示します。ダイアログでパスワードを入力したら、「次へ」をクリックして、「表領域のマップ」ダイアログを表示します。このダイアログには表領域のサマリーが表示されます。デフォルト表領域を1つと一時表領域を1つ使用します。デフォルトの表領域名は、それぞれPREFIX_IAS_OPSSおよびPREFIX_IAS_TEMPです。

    デフォルト以外の表領域またはデータファイルを作成する場合は、「表領域の管理」ボタンをクリックして、「表領域の管理」ダイアログを表示します。表示されたダイアログで、表領域またはデータファイルを作成するための情報を入力します。入力が終了したら、「OK」をクリックします。入力した表領域がデータベースにまだ存在しない場合は、その表領域が作成され、その内容が、表領域の作成中に表示されます。「OK」をクリックすると、「サマリー」ダイアログに、入力したデータのサマリーが表示されます。続いて、「作成」をクリックして、追加の表領域またはデータファイルの作成を有効にします。

  5. 作成が完了すると、「完了サマリー」に、データベースの詳細が表示されます。

  6. 次に示すようにSQLPlusコマンドを呼び出して、データベース・スキーマが適切に作成されていることを確認します。

    SQL> desc jps_dn;

8.3.1.2 OracleデータベースでのOPSSスキーマの削除

OPSSスキーマの削除は、OPSSセキュリティ・ポリシーの格納用としてそのDBを使用しなくなった場合にのみ必要です。

OPSSスキーマが正常に作成された後で、RCUを使用して、次のようにOPSSスキーマを削除します。

  1. RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの削除」ページを表示します。

  2. そのページで「削除」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。

  3. そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。続いて、「次へ」をクリックして、「コンポーネントの選択」ダイアログを表示します。

  4. そのダイアログで、接頭辞を選択し、「コンポーネント」階層で、「AS共通スキーマ」および「Oracle Platform Security Services」を選択します。「次へ」をクリックして「サマリー」ページを表示します。

  5. そのページで、収集された詳細情報が正しいことを確認し、「削除」をクリックして削除処理を起動します。正常に処理が完了すると、「完了サマリー」ページに、削除されたスキーマの詳細情報が表示されます。

8.3.1.3 データソース・インスタンスの作成

Oracle WebLogic管理コンソールを使用してWebLogicドメイン内にJDBCデータソースを作成するには、次の手順を実行します。

  1. コンソールにログインし、「サービス」→「データソース」に移動して、「新規」→「汎用データソース」を選択します。

  2. 「JNDI名」を入力し、「次へ」をクリックします。この名前は、jps-config.xmlファイルでのDBベース・ストアの構成に使用することに注意してください。

  3. 「データベース・ドライバ」プルダウンで、「Oracleのインスタンス接続用ドライバ(Thin)、バージョン:9.0.1以降」(これは非XA JDBCドライバです)を選択し、「次へ」をクリックします。

  4. 「グローバル・トランザクションのサポート」の選択が解除されていることを確認し、「次へ」をクリックします。

  5. 「接続プロパティ」領域で、「データベース名」、「ホスト名」、「ポート」、「データベース・ユーザー名」および「パスワード」にデータを入力します。「次へ」をクリックします。

  6. 設定を検証してテストし、問題がなければ「終了」をクリックします。

  7. 作成したデータソースを適切なサーバーにデプロイします。

前述の手順の詳細は、Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理のJDBCデータソースの作成に関する項を参照してください。

WebSphere Application Serverでデータソースを設定するには、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。


注意:

11.2のOracle JDBCドライバでは、Etc/UCT、UCT、Etc/UTC、Etc/Universal、Etc/ZuluおよびUniversalのタイムゾーンは非推奨です 。Oracle JDBCドライバのタイムゾーンを設定したら、そのタイムゾーンが、非推奨ではないことを確認してください。

8.3.2 DBベースのセキュリティ・ストアのメンテナンス

この項では、管理者が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);

8.3.3 DBへのSSL接続の設定

DBベースのOPSSセキュリティ・ストアへの一方向または双方向SSL接続の確立はオプションであり、詳細は『Oracle Fusion Middleware管理者ガイド』のデータベースでのSSLの構成に関する項を参照してください。

SSL関連のトピックの補足情報は、次のドキュメントを参照してください。

8.4 OPSSセキュリティ・ストアの構成

Java SEアプリケーション用のストア構成の例は、第23.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。

Java EEアプリケーション用のストア構成の例は、例1および例4を参照してください。

その他のアーティファクトの構成に関する詳細は、「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。

8.5 OPSSセキュリティ・ストアの再関連付け

OPSSセキュリティ・ストアの再関連付けとは、ポリシー 、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみサポートされています。DBタイプのターゲットでは、DB_ORACLEのみサポートされています。

再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。再関連付けでは、各セキュリティ・アーティファクトに対して、ターゲット・ストアを検索し、一致するストアが見つかった場合は、一致するアーティファクトが更新され、見つからない場合は、新しいアーティファクトが作成されます。

再関連付けを実行する代表的な例として、すぐに使用可能なファイルベース・ストアのかわりに、LDAPベースまたはDBベースのOPSSストアをドメインで使用するように設定する場合があります。この操作は、OPSSストアの構成およびインスタンス化の後であればいつでも行うことができます。また、この操作は、次の項で説明されているように、Fusion Middleware ControlまたはreassociateSecurityStoreのいずれかを使用して実行します。

8.5.1 Fusion Middleware Controlを使用した再関連付け

再関連付けでは、OPSSポリシー・ストア(ポリシー、資格証明、およびキー)をリポジトリ間で移行し、適切なセキュリティ・ストア・プロバイダを構成します。この項では、Fusion Middleware Controlのページを使用して再関連付けを行う方法を説明します。

「セキュリティ・プロバイダ構成」ページのその他の使用方法については、「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。

重要ポイント

Fusion Middleware Controlを使用してOPSSセキュリティ・ストアを再関連付けする手順は、次のとおりです。

  1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」(Oracle WebLogic Serverに接続している場合)、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」(WebSphere Application Serverに接続している場合)に移動して、「セキュリティ・プロバイダ構成」ページを表示します(次の図にページの一部を示します)。

    emsecprovconf.gifについては周囲のテキストで説明しています。

    「セキュリティ・ストア」領域の表には、現在ドメインで構成されているプロバイダの特性が表示されます。

  2. 「アソシエーションの変更」ボタンをクリックして、「セキュリティ・プロバイダの設定」ページを表示し、プルダウン・リストから「ストア・タイプ」を選択します。このページに表示されるテキストは、選択したストア・タイプによって異なります。次の図に、Oracle Internet Directoryを選択した場合のこのページの一部を示します。

    emsetsecprvdr.gifについては周囲のテキストで説明しています。

  3. 「データベース」を選択している場合は、「データソース名」ボックスにデータソース名を入力します。これは、データソースの作成時に入力したJDBCデータソース名にする必要があります(詳細は、「データソース・インスタンスの作成」を参照)。必要に応じて、「選択」をクリックして、構成済のデータソース名のリストを取得します。

  4. 「Oracle Internet Directory」を選択している場合は、「LDAPサーバーの詳細」領域で、ターゲットのLDAPサーバーの詳細と接続情報を入力します。

    1. ターゲットのOracle Internet Directory LDAPサーバーのホスト名とポート番号を入力します。

    2. オプションで、「SSLを接続に使用」ボックスを選択し、LDAPサーバーへの匿名SSL伝送を確立します。

      このチェック・ボックスを選択するときには、次の点に注意してください。

      ターゲットLDAPサーバーのポートは、匿名SSL伝送を処理するように構成されている必要があります。このポートは、デフォルトの(セキュアではない)LDAPサーバー・ポートとは異なります。

      再関連付けでターゲットLDAPストアへの一方向SSLを使用する場合は、この手順を実行する前に、「LDAPへの一方向SSL接続の設定」で説明する手順を必ず実行してください。一方向SSL接続の設定で、一方向SSLチャネルをサポートするポートを特定し、以降の手順でそのポートを指定します。今回のリリースでは、双方向SSLチャネルを使用した再関連付けはサポートされていません。

      Fusion Middleware Controlによって、匿名SSL接続をサポートするために必要な権限が追加されて、ファイルweblogic.policyが変更されます。

    3. 「接続DN」テキスト・ボックスに、1から256文字の文字列で完全な識別名を入力します。たとえば、cn=orcladmin、dc=us、dc=oracle、dc=comです。

    4. 「パスワード」ボックスに、1から256文字を含む文字列であるユーザー・パスワードを入力します。

    5. 入力したデータを使用したLDAPサーバーへの接続が機能することを確認するには、「LDAP認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第L.9項「匿名SSL接続の確立の失敗」を参照してください。

  5. 「ルート・ノードの詳細」領域で、「ルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。

    この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第L.2項「再関連付けの失敗」を参照してください。

  6. 必要に応じて「ポリシー・ストアのプロパティ」領域と「資格証明ストアのプロパティ」領域に、「遅延ロードの有効化」や「ロール・メンバーのキャッシュ・サイズ」などのサービス・インスタンスのプロパティを入力します。

    新規のプロパティを追加するには、「追加」をクリックし、「新規プロパティの追加」ダイアログ・ボックスで「プロパティ名」と「値」に文字列を入力して、「OK」をクリックします。追加されたプロパティと値のペアが、表「カスタム・プロパティ」に表示されます。

    これらのプロパティは通常、インスタンスの作成時にインスタンスを初期化するために使用されます。

    ドメイン構成ファイルjps-config.xmlにあるLDAPサービス・インスタンスの構成に、入力したプロパティと値を指定した<property>要素が追加されて、この構成ファイルが変更されます。

    サービス・インスタンスの変更例として、プロパティ名fooと値barを入力したとします。この場合は、次に示すような<property>要素が追加され、LDAPサービス・インスタンスの構成が変更されます。

    <serviceInstance name="myNewLDAPprovider" provider="someProvider"
  ...
  <property name="foo" value="bar"/>
  ...
</serviceInstance>

  7. データの入力を完了したら、「OK」をクリックし、「セキュリティ・プロバイダ構成」ページに戻ります。再関連付けのステータスを示すダイアログ・ボックスが表示されます。「セキュリティ・ストア」領域の表が変更されて、指定したプロバイダが表示されます。

  8. アプリケーション・サーバーを再起動します。サーバーが再起動するまで、変更は有効になりません。

再関連付けによって、ドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成がすべて削除され、新しいストア・プロバイダの構成が追加されます。それにより、ポリシーと資格証明に関する情報が移行元ストアから移行先ストアに移動します。

移行先ストアがLDAPベースの場合、これらの情報は次の形式に従ってドメインDNの下位に保存されます。

cn=<domain_name>,cn=JpsContext,<JPS ROOT DN>

インストールの構成が上位のドメインDNに依存しているかぎり、その上位ドメインのノードはLDAPサーバーから削除しないでください。

8.5.1.1 Oracle Internet Directoryノードへのアクセスの保護

この項で説明する手順は必要に応じて実行するものであり、Oracle Internet Directoryにアクセスするときのセキュリティを強化することのみを目的としています。

アクセス制御リスト(ACL)とは、情報にアクセスできるユーザーとOracle Internet Directoryディレクトリ・オブジェクトに対して許可される操作を指定したリストです。この制御リストはノードで指定し、そのノードのすべてのサブツリーにあるすべてのエントリに、リストで指定した制限が適用されます。

ACLを使用して、LDAP Oracle Internet Directoryリポジトリに格納されているポリシー・データおよび資格証明データへのアクセスを制御できます。ACLは通常、ストアの最上位のルート・ノードで指定します。

Oracle Internet DirectoryリポジトリのノードでACLを指定する手順は、次のとおりです。

  1. 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)を表します。

  2. 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章を参照してください。

8.5.2 スクリプトreassociateSecurityStoreを使用した再関連付け

OPSSストアは、OPSSスクリプトreassociateSecurityStoreを使用して再関連付けできます。詳細は、第9.3.29項「reassociateSecurityStore」を参照してください。

8.6 OPSSセキュリティ・ストアの移行

1つのドメインに設定できるポリシー・ストアは1つのみです。アプリケーションで独自のポリシーを指定することはできますが、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはそのポリシー・ストアのポリシーとして格納されます。したがって、ドメインにデプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるポリシー・ストアを使用します。ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。

OPSSセキュリティ・ストアの移行とは、ポリシー 、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第L.21項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。

アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。

ポリシー・ストアの構成は、管理者が行います。

この章の内容は次のとおりです。


注意:

WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティ jps.deployment.handler.disabledを使用します。

このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイルweblogic-application.xmlにあるアプリケーション個別の設定は無視されます。

8.6.1 Fusion Middleware Controlを使用した移行

アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。

アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。

詳細は、第6.5.2項「デプロイ時のポリシーおよび資格証明の移行」の手順を参照してください。

8.6.2 スクリプトmigrateSecurityStoreを使用した移行

アプリケーション固有のポリシーまたはシステム・ポリシーは、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。

このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。


注意:

スクリプトmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、第6.5.2.3項「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。

OPSSスクリプトとその構文の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドのカテゴリの概要に関する項を参照してください。

OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。

WebLogicのすべてのポリシー(すべてのアプリケーションのシステム・ポリシーとアプリケーション固有のポリシー)を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type policyStore
                        -configFile jpsConfigFileLocation
                        -src srcJpsContext
                        -dst dstJpsContext

migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

引数(すべて必須)の意味は、次のとおりです。

  • configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。通常、この構成ファイルはスクリプトで使用するためにのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのjps-contextがあります。

    また、1つまたは2つのLDAPベースのストアを移行する場合は、このファイルにcwallet.ssoファイルの場所を参照するブートストラップjps-contextを含める必要があります。このファイルには、移行対象のLDAPベースのストアにアクセスするための資格証明が格納されます。

  • 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) ソースおよびターゲットのコンテキスト名が一意。

8.6.2.1 使用例

このスクリプトの使用方法を示す例は、第6.5.2.1項「ポリシーの手動による移行」を参照してください。

8.7 アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成

この項では、Fusion Middleware Controlを使用して、ユーザー/ロールAPI、プロパティおよびプロパティ・セットで使用するパラメータを構成し、シングル・サインオン・プロバイダを指定する方法を説明します。この項の内容は次のとおりです。


注意:

「セキュリティ・プロバイダ構成」ページの「Web Services Managerの認証プロバイダ」領域は、Web Services Managerのログイン・モジュールとキーストアの構成にのみ関連します。ADFアプリケーションとJava EEアプリケーションには関連しません。

使用可能なログイン・モジュールとそのパラメータ、およびそれらのコンポーネントのキー・ストアの詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の第9章を参照してください。

8.7.1 アイデンティティ・ストア・プロバイダの構成

アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータを構成する手順は、次のとおりです。

  1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

  2. 必要に応じて、「アイデンティティ・ストア・プロバイダ」領域を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。

  3. 必要に応じて、「追加」ボタンと「削除」ボタンを使用してカスタム・プロパティを管理します。

  4. 完了したら、「OK」をクリックして設定を保存し、「セキュリティ・プロバイダ構成」ページに戻ります。

8.7.2 プロパティとプロパティ・セットの構成

プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。

OPSS構成プロパティのリストは、付録F「OPSS構成プロパティ」を参照してください。

プロパティおよびプロパティ・セットの定義には、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlで<property>要素と<properySet>要素を使用します。プロパティ・セットは、<propertySetRef>要素で参照できます。

プロパティまたはプロパティ・セットを定義する手順は、次のとおりです。

  1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

  2. 必要に応じて、「拡張プロパティ」領域を開き、「構成」をクリックして「拡張プロパティ」ページを表示します。このページで、プロパティおよびプロパティ・セットを入力できます。

  3. プロパティを入力するには、「プロパティ」領域の「追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。完了したら、「OK」をクリックします。入力したプロパティが「プロパティ」の表に表示されます。

  4. プロパティ・セットを入力するには、「プロパティ・セット」領域の「プロパティ・セットの追加」をクリックして「プロパティ・セットの追加」ダイアログ・ボックスを表示し、プロパティ・セット名を入力します。

  5. プロパティ・セットにプロパティを入力するには、既存のプロパティ・セットを選択し、「プロパティの追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。入力したプロパティが、選択したプロパティ・セットのプロパティのリストに追加されます。

  6. どの表でも、選択した項目をその表から削除するには、「削除」ボタンを使用します。プロパティおよびプロパティ・セットの入力または編集が完了したら、「OK」をクリックします。

  7. Oracle WebLogic Serverを再起動します。サーバーが再起動するまで、変更は有効になりません。

プロパティ・セットを追加または削除するとドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されますが、サーバーを再起動しないかぎり、その変更は有効になりません。

前述の手順で追加した<property>要素と<propertySet>要素は、<jpsConfig>要素の直下に挿入されます。

8.7.3 シングル・サインオン・ソリューションの指定

この項では、OPSSシングル・サインオン(SSO)フレームワークを説明し、Fusion Middleware Controlを使用してSSOソリューションを構成する方法を紹介します。この項の内容は、次のとおりです。

8.7.3.1 OPSS SSOフレームワーク

OPSS SSOフレームワークにより、ドメインにあるアプリケーションをSSOソリューションに統合できます。具体的には、複数のSSO製品に共通のAPIセットをアプリケーションに提供することで、ログイン、ログアウトおよび自動ログインを処理します。

これらのソリューションの1つであるOAMソリューションは特別な設定をせずに使用でき、次の機能が用意されています。

  • 動的認証: 認証が必要な保護されたアーティファクトの一部にユーザーがアクセスすると、アプリケーションが認証をトリガーし、ユーザーを適切なソリューションで認証できるようにリダイレクトします。

  • 自動ログイン: 最初に匿名でアプリケーションにアクセスしたユーザーが、そのアプリケーションにアカウントを登録します。正常に登録されると、そのユーザーは認証のURLにリダイレクトされます。また、プロンプトの表示なしで自動的にログインすることも可能です。

  • グローバル・ログアウト: ユーザーが1つのアプリケーションからログアウトすると、ソリューションで有効になっているあらゆるアプリケーションにそのログアウトが伝播されます。

OAMソリューションの構成例は、「OAM構成の例」を参照してください。

SSOソリューションでは、ユーザーがアプリケーションにログインおよびログアウトするための標準的な手段を用意する必要があります。ユーザーが正常に認証された後は、SSOサービスがユーザーを適切なURLにリダイレクトします。そのためには、このソリューションの適用先であるドメインが、ログイン前とログアウト後には匿名のユーザーとロールをサブジェクトに追加でき、ログイン後には認証されたロールをサブジェクトに追加できるように構成されていることが前提となります。また、SSOプロバイダが資格証明マッピング・サービスを実装していることも前提となっています。すぐに使用できるOAMソリューションの場合、プロバイダは適切なOAMトークンを生成するCredentialMapperServiceを実装しています。

OPSS SSOフレームワークは、複数レベルの認証をサポートしていません。

目的のSSOソリューションと統合するには、そのSSOソリューションを個別にインストールして、適切に構成する必要があります。推奨ソリューションの詳細は、第IV部「シングル・サインオンの構成」を参照してください。

8.7.3.2 Fusion Middleware Controlを使用したSSOソリューションの構成

ドメインで使用するSSOソリューションを指定する手順は、次のとおりです。

  1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

  2. そのページで、「シングル・サインオン・プロバイダ」領域の「構成」をクリックして、「シングル・サインオン・プロバイダ」ページを表示します。

  3. そのページで、「シングル・サインオン・プロバイダ」ボックスを選択して、プロバイダのデータを入力できるようにします。このボックスを選択するまで、すべてのボックスはグレー表示になっています。

  4. プルダウン・リストから「プロバイダ・タイプ」を選択し、選択したプロバイダに該当するデータを入力します(必要なデータは、選択したタイプによって異なります)。

  5. プルダウン・リストから「認証レベル」を選択します。

  6. 必要に応じ、ページの下部にある「追加」、「編集」および「削除」を使用してプロバイダの「カスタム・プロパティ」を管理します。

  7. 完了したら、「OK」をクリックして、入力したデータを保存します。

8.7.3.3 OAM構成の例

「Fusion Middleware Controlを使用したSSOソリューションの構成」の手順で入力したSSOサービスの構成は、jps-config.xmlファイルに書き込まれます。指定するデータは次のとおりです。

  • 特定のSSOサービス

  • 自動ログインのURIおよび自動ログアウトのURI

  • 認証レベル

  • 選択したSSOサービスで返されるURLに記述される問合せパラメータ

  • トークン生成のための適切な設定

jps-config.xmlファイルにある次のコードはOAM SSOプロバイダの構成を示しています。

<propertySets>
  <propertySet name = "props.auth.url">
    <property name = "login.url.BASIC" value = "http://host:port/oam_login.cgi?level=BASIC"/>
    <property name = "login.url.FORM" value = "http://host:port/oam_login.cgi?level=FORM"/>
    <property name = "login.url.DIGEST" value = "http://host:port/oam_login.cgi?level= DIGEST"/>
    <property name = "autologin.url" value = " http://host:port/obrar.cgi"/>
    <property name = "logout.url" value = "http://host:port/logout.cgi"/>
    <property name = "param.login.successurl"  value = "successurl"/>
    <property name = "param.login.cancelurl"   value = "cancelurl"/>
    <property name = "param.autologin.targeturl" value = "redirectto"/>
    <property name = "param.autologin.token"   value = "cookie"/>
    <property name = "param.logout.targeturl"   value = "targeturl"/>
  </propertySet>

  <propertySet name="props.auth.uri">
    <property name="login.url.BASIC" value="/${app.context}/adfauthentication?level=BASIC" /> 
    <property name="login.url.FORM" value="/${app.context}/adfauthentication?level=FORM" /> 
    <property name="login.url.DIGEST" value="/${app.context}/adfauthentication?level=DIGEST" /> 
    <property name="autologin.url" value="/obrar.cgi" /> 
    <property name="logout.url" value="/${app.context}/adfauthentication?logout=true" /> 
  </propertySet>

  <propertySet name = "props.auth.level">
    <property name = "level.anonymous" value = "0"/>
    <property name = "level.BASIC"    value = "1"/>
    <property name = "level.FORM"    value = "2"/>
    <property name = "level.DIGEST"   value = "3"/>
  </propertySet>
<propertySets>

<serviceProviders>
  <serviceProvider name = "sso.provider"
    class = "oracle.security.jps.internal.sso.SsoServiceProvider" 
    type = "SSO">
    <description>SSO service provider</description>
  </serviceProvider>
</serviceProviders>

<serviceInstances>
  <serviceInstance name = "sso" provider = "sso.provider">
    <propertySetRef ref = "props.auth.url"/>
    <propertySetRef ref = "props.auth.level"/>
    <property name = "default.auth.level" value = "2"/>
    <property name = "token.type" value = "OAMSSOToken"/>
    <property name = "token.provider.class" value = "oracle.security.jps.wls.internal.sso.WlsTokenProvider"/>
    <property name="sso.provider.class" value="oracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImpl"/>
  </serviceInstance>
</serviceInstances>

<jpsContexts default = "default">
  <jpsContext name = "default">
    <serviceInstanceRef ref = "sso"/>
  </jpsContext>
</jpsContexts>

表8-1は、SSOプロバイダの構成に関与するプロパティの意味を示しています。

表8-1 SSOプロバイダのプロパティ

プロパティ名 説明

logout.url

SSOプロバイダのログアウトURL。

login.url.BASIC

SSOプロバイダのBASICログアウトURL。

login.url.FORM

SSOプロバイダのFORMログアウトURL。

login.url.DIGEST

SSOプロバイダのDIGESTログアウトURL。

autologin.url

自動ログイン用の自動登録URL。

logout.url

SSOプロバイダのログアウトURL。

param.login.successurl

ログインの成功後のURLリダイレクト。

param.login.cancelurl

問合せの取消し後のURLリダイレクト。

param.autologin.targeturl

自動ログイン後のURLリダイレクト。

param.autologin.token

自動ログイン用のトークン。

param.logout.targeturl

ログアウト後のURLリダイレクト。

SSOプロバイダの構成については、次の重要な注意点に留意してください。

  • すべてのSSOプロバイダは、少なくともFORMログイン用のURIをプロパティlogin.url.FORMで定義する必要があります。値はURLである必要はありません。

  • アプリケーションで自動登録ページのURIまたはURLがサポートされている場合は、それをプロパティautologin.urlで指定する必要があります。

  • SSOソリューションでグローバル・ログアウトのURIまたはURLがサポートされている場合は、それをプロパティlogout.urlで指定する必要があります。OAMソリューションではグローバル・ログアウトがサポートされています。

  • 前述の例にある次のプロパティはオプションです。

    • param.login.successurl

    • param.login.cancelurl

    • param.autologin.targeturl

    • param.login.token

    • param.logout.targeturl

  • 前述の例でプロパティ・セットprops.auth.uri内の値で示された、URI指定の変数app.contextは、ADFアプリケーションがOAMソリューションと統合している場合にのみ使用できます。

  • プロパティ・セットprops.auth.levelは必須です。

  • props.auth.urlへの参照は必須です。

  • SSOプロバイダのサービス・インスタンス内のプロパティsso.provider.classは、固有のSSOソリューションを実装するクラスの完全修飾名です。

    OAMソリューションの場合、提供されているクラス名はoracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImplです。

  • SSOプロバイダのサービス・インスタンス内のプロパティdefault.auth.levelは、上記の例に示されているとおり、2に設定する必要があります。

  • SSOプロバイダのサービス・インスタンス内のプロパティtoken.typeは必須です。

    このトークンのタイプは、正常な認証後にSSOプロバイダが発行するHTTPリクエストのトークン・セットを特定します。2回目以降は、このトークンがSSOプロバイダで使用されるので、ユーザーの再認証が不要となり、ユーザーのサインオンが引き続き有効となります。OAMソリューションの場合、上記の例に示されているとおり、トークン・タイプをOAMSSOTokenとします。

  • SSOプロバイダのサービス・インスタンス内のプロパティtoken.provider.classは、トークン・クラスの完全修飾名で、プロバイダ固有です。

  • 自動登録論理を実装したアプリケーションで、正常な自動登録後はユーザーが自動的にログインできるようにする場合、そのアプリケーションではOPSS autoLogin APIをコールする必要があります。このコールを可能にするには、クラスがJpsPermissionであるCredentialMappingというコード・ソースのパーミッションをそのアプリケーションに付与する必要があります。

    system-jazn-data.xmlファイルにある次のコードでは、アプリケーションMyAppに対してこのパーミッションを指定しています。

    <grant>
  <grantee>
    <codesource>
     <url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}
     </url>
    </codesource>
  </grantee>
  <permissions>
    <permission>
      <class>oracle.security.jps.JpsPermission</class>
      <name>CredentialMapping</name>
    </permission>
  </permissions>
</grant>

    URLの指定に使用するシステム変数に注意してください。詳細は、<url>の例を参照してください。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引