OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーが格納されるリポジトリです。ポリシーおよび資格証明の概要は、次の各項を参照してください。
この章では、ポリシーと資格証明に共通のOPSSセキュリティ・ストアの機能について説明します。この章の内容は次のとおりです。
JavaEEおよびWebLogicのセキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のJavaEEおよびWebLogicのセキュリティに関する項を参照してください。
注意: この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。 |
OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。
OPSSセキュリティ・ストアは、選択したリポジトリ・タイプに応じてファイルベース、LDAPベース、またはDBベースにすることができます。また、ファイルベースからLDAPまたはDBベース、DBベースからLDAPまたはDBベース、LDAPベースからLDAPまたはDBベースに再関連付けができます(つまり、リポジトリ・タイプは変更可能ということです)。これ以外の再関連付けはサポートされていません。OPSSセキュリティ・ストアの再関連付けに使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した再関連付けおよびスクリプトreassociateSecurityStoreを使用した再関連付けの項を参照してください。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。
JavaEEアプリケーションに関するセキュリティ・データは、通常、アプリケーションとともにパッケージされているため、デプロイ時にOPSSセキュリティ・ストアに移行できます。OPSSセキュリティ・ストアへの移行に使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した移行およびスクリプトmigrateSecurityStoreを使用した移行の項を参照してください。
LDAPベースのポリシー・ストアは、通常、本番環境で使用します。今回のリリースでサポートされているLDAPサーバーは、Oracle Internet Directory(リリース10.1.4.3以降)のみです。
注意: バージョンに応じて、次のパッチをOracle Internet Directoryに適用する必要があります。
パッチを適用するには、次のようにします。
|
ドメインでLDAPベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。
サービス・インスタンスで指定可能なプロパティの一覧は、付録F「LDAPベースのすべてのインスタンスに共通するプロパティ」を参照してください。
この項の内容は次のとおりです。
複数のマシンに複数のサーバー・インスタンスが分散されているドメインでは、OPSSセキュリティ・ストアをLDAPベースまたはDBベースにすることを強くお薦めします。
通常、アプリケーションによってポリシー、資格証明、またはキーのデータが変更されることはありません。そのような変更が発生した場合は、それらの変更がドメインにあるすべての管理対象サーバーとクラスタに適切に伝播されることが重要です。したがって、このような変更は、管理対象サーバーではなく、ドメイン管理サーバーで実行することを強くお薦めします。
単一ノード・サーバー・ドメインの場合は、セキュリティ・データのローカル変更の伝播を考慮する必要はありません。このシナリオでは、ローカル変更はグローバル変更と同じです。
ただし、複数ノード・サーバー・ドメインでは、ファイルベースのポリシーに対するローカル変更は、JMXフレームワークによってそれぞれのランタイム環境に伝播されるため、キャッシュ・ポリシーと構成に基づいてデータが更新されます。ポリシーおよび資格証明に設定可能なプロパティの詳細は、付録F「ポリシー・ストアのプロパティ」および付録F「資格証明ストアのプロパティ」を参照してください。
要約すると、複数ノード・サーバー環境における推奨事項は次のとおりです。
ポリシー・ストアと資格証明ストアの両方を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ディレクトリにノードを設定する手順は、次のとおりです。
次の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セキュリティ・ストアの再関連付け」を参照してください。
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スクリプトを使用し、その資格証明ストアを構成する必要があります。
構成可能なプロパティの一覧は、付録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 jps_dn;
OPSSスキーマの削除は、OPSSセキュリティ・ポリシーの格納用としてそのDBを使用しなくなった場合にのみ必要です。
OPSSスキーマが正常に作成された後で、RCUを使用して、次のようにOPSSスキーマを削除します。
RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの削除」ページを表示します。
そのページで「削除」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。
そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。続いて、「次へ」をクリックして、「コンポーネントの選択」ダイアログを表示します。
そのダイアログで、接頭辞を選択し、「コンポーネント」階層で、「AS共通スキーマ」および「Oracle Platform Security Services」を選択します。「次へ」をクリックして「サマリー」ページを表示します。
そのページで、収集された詳細情報が正しいことを確認し、「削除」をクリックして削除処理を起動します。正常に処理が完了すると、「完了サマリー」ページに、削除されたスキーマの詳細情報が表示されます。
データソース・インスタンスの作成方法は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のJDBCデータソースの作成に関する項を参照してください。この項の手順で入力したJDBCデータソースのJNDI名は、DBベースのストアを構成する際に使用します。
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文の実行計画を最適化する際に使用できます。
DBMS_STATS
パッケージを使用して、DBスキーマに関する情報を収集するサンプルを次に示します。
EXEC DBMS_STATS.GATHER_SCHEMA_STATS('OPSS_DEV', DBMS_STATS.AUTO_SAMPLE_SIZE);
OPSS_DEV
は、RCUの設定時(OracleデータベースでのOPSSスキーマの作成の項を参照)に作成されたDBスキーマの名前です。DBMS_STATS
パッケージの詳細は、『Oracle Database管理者ガイド』を参照してください。
この項では、DBベースのOPSSセキュリティ・ストアに対して、一方向または双方向のSSL接続を確立する方法について説明します。この設定はオプションです。次の各項で設定に必要な手順を説明します。
SSL関連のトピックの補足情報および詳細情報は、次のドキュメントを参照してください。
Oracle JDBC Thin Driverを使用したSSL: http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/wp-oracle-jdbc_thin_ssl_2007.pdf.
Oracle Database JDBC開発者ガイド
Oracle DBサーバーにSSLを構成するには、DBサーバーが実行されているホストでOracle Wallet Managerを起動し、このツールを使用して次の手順を実行します。
ウォレットを作成します。
信頼できる認証局(CA)から証明書を入手して、作成したウォレットにインポートします。
DBサーバーの証明書リクエストを作成します。
証明書リクエストをCAに送信して、署名付き証明書をCAから入手します。
署名付き証明書をウォレットにインポートします。この証明書はDBサーバーの証明書です。
メニュー「ウォレット」で「自動ログイン」ボックスを選択し、DBサーバーでウォレットが選択されるようにします。
ウォレットを保存します。
DBサーバーが実行されているホストでOracle Net Managerを起動し、このツールを使用して次の手順を実行します。
「Oracle Netの構成」→「ローカル」→「プロファイル」に移動して、「Oracle Advanced Security」を選択し、「SSL」タブをクリックします。
そのタブで、「ウォレット・ディレクトリ」に、前述のステップ7で保存したウォレットを設定し、サーバーのSSL構成を選択します。双方向SSLの場合は、「クライアントの認証が必要」ボックスを選択します。
次の手順に従ってリスナーを設定します。
「Oracle Netの構成」→「ローカル」→「リスナー」→「LISTENER」に移動します。
アドレスを追加します(推奨ポート番号は2484)。
そのプロトコルに「SSL付きTCP/IP」を設定します。
必要に応じて、SSLを使用してホスト上のDBに接続するTNSサービスを作成する場合は、次の手順を実行します。
「Oracle Netの構成」→「ローカル」→「サービス・ネーミング」に移動します。
新規サービスを作成します。
そのプロトコルに「SSL付きTCP/IP」を設定します。
リスナーに入力したポート番号を、そのサービスのポート番号に設定します。
ネットワーク構成を保存して、DBリスナーを再起動します。この時点で、DBサーバーの指定したポートでSSLがサポートされているはずです。
次の断片は、前述の手順が完了した後のsqlnet.ora
、listener.ora
、およびtnsnames.ora
の各ファイルの一部を示しています(ファイルはすべて$ORACLE_HOME/network/admin
にあります)。
sqlnet.ora QLNET.AUTHENTICATION_SERVICES= (BEQ, TCPS) SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /myHome/owm/wallets/myWallets) ) ) listener.ora SSL_CLIENT_AUTHENTICATION = FALSE WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /myHome/owm/wallets/myWallets) ) ) LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = myHost.com)(PORT = 1521)) ) (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = myHost.com)(PORT = 2484)) ) ) tnsnames.ora ORCLSSL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCPS)(HOST = myHost.com)(PORT = 2484)) ) (CONNECT_DATA = (SERVICE_NAME = myService.com) ) )
この項では、SSLを介してクライアントをDBサーバーに接続する方法を説明します。この項の内容は次のとおりです。
このタスクでは、信頼できる証明書(一方向SSLの場合)およびクライアント証明書(双方向SSLの場合)を指定する必要があります。
クライアントが実行されているホストで、Oracle Wallet Managerを起動し、このツールを使用して次の手順を実行します。
ウォレットを作成して、DBサーバーの信頼できるCA証明書(Oracle DBサーバーでのSSLの構成の項の最初の手順で作成済)をインポートします。
双方向SSLを確立する手順は次のとおりです。
証明書リクエストを作成します。
CA証明書を使用してその証明書に署名します。
ウォレットに証明書をインポートします。この証明書は、双方向SSLを介してDBサーバーに接続する際にクライアント証明書として使用します。
メニュー「ウォレット」の「自動ログイン」チェック・ボックスを選択します。
ウォレットを保存します。
sqlplusを使用してサーバーに接続する場合は、「Oracle Netの構成」→クライアントのSSL構成→「サービス・ネーミング」に移動し、Oracle Net Managerを使用してTNSサービスを作成します。
重要: このTNSサービスの「サーバーX.509の名前に一致」を「はい」に設定する場合、次に示すように、「SSL_SERVER_CERT_DN」の値を、DBサーバー証明書に設定されているDNと同じ値にする必要があります(CN=dbserver,OU=OPSS,O=Oracle,ST=Beijing,C=CN は、DBサーバー証明書のDN)。
(SECURITY= (SSL_SERVER_CERT_DN="CN=dbserver,OU=OPSS,O=Oracle,ST=Beijing,C=CN") ) |
このシナリオの手順は次のとおりです。
次のSSL固有の設定を使用して「JDBC URL」を設定します。
PROTOCOL=TCPS
SECURITYには、SSL SERVER_CERT_CNの適切な値を設定
次の断片は、この設定を示しています。
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=myServer.us.oracle.com)(PORT=2484)))(CONNECT_DATA=(SERVICE_NAME=orcl.us.oracle.com))(SECURITY=(SSL_SERVER_CERT_DN="CN=dbserver,OU=OPSS,O=Oracle,ST=Beijing,C=CN")))
次のシステム・プロパティに適切な値を設定します。
oracle.net.ssl_server_dn_match javax.net.ssl.trustStore javax.net.ssl.trustStoreType javax.net.ssl.trustStorePassword javax.net.ssl.keystore javax.net.ssl.keyStoreType javax.net.ssl.keyStorePassword
J2SEアプリケーションの場合は、JVMの起動時に-Dオプションを使用して、前述のプロパティを設定します。
Oracle WebLogic Serverのデータソースの場合は、WebLogic管理コンソールを使用して、「データ・ソース」の「構成」タブ→「接続プール」で前述のプロパティと値を指定します。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。
WebSphere Application Serverのデータソースの場合は、Administration Consoleを使用して、次の手順を実行します。
「Data Sources」→「YourDataSourceName」→「Custom Properties」に移動します。
次の行に示す値を使用して、新しいカスタム・プロパティconnectionProperties
を作成します。
oracle.net.ssl_server_dn_match=true;javax.net.ssl.trustStore=/scratch/weiniu/work/certs/qatestca.jks;javax.net.ssl.trustStoreType=JKS;javax.net.ssl.trustStorePassword=welcome1;javax.net.ssl.keyStore=/scratch/weiniu/work/certs/jksuser1.jks;javax.net.ssl.keyStoreType=JKS;javax.net.ssl.keyStorePassword=welcome1;oracle.net.ssl_version=3.0
値はセミコロンで区切り、oracle.net.ssl_version=3.0
を設定する必要があります。
JavaSEアプリケーション用のストア構成の例は、第24.1項「JavaSEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。
JavaEEアプリケーション用のストア構成の例は、例1および例4を参照してください。
その他のアーティファクトの構成に関する詳細は、「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。
OPSSセキュリティ・ストアの再関連付けとは、ポリシー 、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみサポートされています。DBタイプのターゲットでは、DB_ORACLEのみサポートされています。
再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。再関連付けでは、各セキュリティ・アーティファクトに対して、ターゲット・ストアを検索し、一致するストアが見つかった場合は、一致するアーティファクトが更新され、見つからない場合は、新しいアーティファクトが作成されます。
再関連付けを実行する代表的な例として、すぐに使用可能なファイルベース・ストアのかわりに、LDAPベースまたはDBベースのOPSSストアをドメインで使用するように設定する場合があります。この操作は、OPSSストアの構成およびインスタンス化の後であればいつでも行うことができます。また、この操作は、次の項で説明されているように、Fusion Middleware ControlまたはreassociateSecurityStore
のいずれかを使用して実行します。
再関連付けでは、OPSSポリシー・ストア(ポリシー、資格証明、およびキー)をリポジトリ間で移行し、適切なセキュリティ・ストア・プロバイダを構成します。この項では、Fusion Middleware Controlのページを使用して再関連付けを行う方法を説明します。
「セキュリティ・プロバイダ構成」ページのその他の使用方法については、「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。
重要ポイント
ターゲットのLDAPストアに再関連付けを行う前に、「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。
ターゲットのDBストアに再関連付けを行う前に、「DBベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。
再関連付けで一方向SSLが必要な場合は、再関連付けを行う前に、「一方向SSL接続の設定」の手順を実行してください。
LDAPストアへの再関連付けの後、Oracle Internet Directoryストアのルート・ノードへのアクセスを保護するために、「Oracle Internet Directoryノードへのアクセスの保護」で説明する手順を実行してください。
再関連付けで生成されたjps-config.xml
ファイルは、J2EEアプリケーションにのみ適しています。J2SEアプリケーションの場合は、第24.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サーバー・ポートとは異なります。
再関連付けで一方向SSLを使用する場合は、この手順を実行する前に、「一方向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 WebLogic ServerまたはJ2SEアプリケーションと、再関連付けのターゲットであるLDAP Oracle Internet Directory間で一方向SSLチャネルを設定する方法を説明します。この設定はオプションです。ただし、設定が必要な場合は、OPSSセキュリティ・ストアを再関連付けする前に行う必要があります。
前提条件: 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のタイプがサーバー認証の場合は、次の手順が必要です。それ以外(認証なしまたはクライアント認証)の場合には、次の手順は不要です。
次の手順で指定するフラグを複数アプリケーション環境で使用する場合は、それらすべてのアプリケーションでトラスト・ストアを共有する必要があります。
J2EEアプリケーションの場合の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
J2SEアプリケーションの場合のWebLogic Serverの設定
J2SEアプリケーションの場合、アイデンティティ・ストア・サービスとポリシー・ストア・サービスの設定は同じです。
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>
この項で説明する手順は必要に応じて実行するものであり、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.29項「reassociateSecurityStore」を参照してください。
1つのドメインに設定できるポリシー・ストアは1つのみです。アプリケーションで独自のポリシーを指定することはできますが、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはそのポリシー・ストアのポリシーとして格納されます。したがって、ドメインにデプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるポリシー・ストアを使用します。ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml
の<applications>
要素で指定したアプリケーション名ごとにストライプが1つずつあります。
OPSSセキュリティ・ストアの移行とは、ポリシー 、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第L.20項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。
アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。
ポリシー・ストアの構成は、管理者が行います。
この章の内容は次のとおりです。
アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xml
で指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。
アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。
詳細は、第6.5.2項「デプロイ時のポリシーおよび資格証明の移行」の手順を参照してください。
アプリケーション固有のポリシーまたはシステム・ポリシーは、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) ソースおよびターゲットのコンテキスト名が一意。
この項では、Fusion Middleware Controlを使用して、ユーザー/ロールAPI、プロパティおよびプロパティ・セットで使用するパラメータを構成し、シングル・サインオン・プロバイダを指定する方法を説明します。この項の内容は次のとおりです。
アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータを構成する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて、「アイデンティティ・ストア・プロバイダ」領域を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。
必要に応じて、「追加」ボタンと「削除」ボタンを使用してカスタム・プロパティを管理します。
完了したら、「OK」をクリックして設定を保存し、「セキュリティ・プロバイダ構成」ページに戻ります。
プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。
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>
要素の直下に挿入されます。
この項では、OPSSシングル・サインオン(SSO)フレームワークを説明し、Fusion Middleware Controlを使用してSSOソリューションを構成する方法を紹介します。この項の内容は、次のとおりです。
OPSS SSOフレームワークにより、ドメインにあるアプリケーションをSSOソリューションに統合できます。具体的には、複数のSSO製品に共通のAPIセットをアプリケーションに提供することで、ログイン、ログアウトおよび自動ログインを処理します。
これらのソリューションの1つであるOAMソリューションは特別な設定をせずに使用でき、次の機能が用意されています。
動的認証: 認証が必要な保護されたアーティファクトの一部にユーザーがアクセスすると、アプリケーションが認証をトリガーし、ユーザーを適切なソリューションで認証できるようにリダイレクトします。
自動ログイン: 最初に匿名でアプリケーションにアクセスしたユーザーが、そのアプリケーションにアカウントを登録します。正常に登録されると、そのユーザーは認証のURLにリダイレクトされます。また、プロンプトの表示なしで自動的にログインすることも可能です。
グローバル・ログアウト: ユーザーが1つのアプリケーションからログアウトすると、OAMソリューションで有効になっているあらゆるアプリケーションにそのログアウトが伝播されます。
OAMソリューションの構成例は、「OAM構成の例」を参照してください。
SSOソリューションでは、ユーザーがアプリケーションにログインおよびログアウトするための標準的な手段を用意する必要があります。ユーザーが正常に認証された後は、SSOサービスがユーザーを適切なURLにリダイレクトします。そのためには、このソリューションの適用先であるドメインが、ログイン前とログアウト後には匿名のユーザーとロールをサブジェクトに追加でき、ログイン後には認証されたロールをサブジェクトに追加できるように構成されていることが前提となります。また、SSOプロバイダが資格証明マッピング・サービスを実装していることも前提となっています。特別な設定を必要とせずに使用できるOAMソリューションの場合、SSOプロバイダは適切なOAMトークンを生成するCredentialMapperServiceを実装しています。
OPSS SSOフレームワークは、複数レベルの認証をサポートしていません。
目的のSSOソリューションと統合するには、そのSSOソリューションを個別にインストールして、適切に構成する必要があります。推奨ソリューションの詳細は、第IV部「シングル・サインオンの構成」を参照してください。
ドメインで使用するSSOソリューションを指定する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
そのページで、「シングル・サインオン・プロバイダ」ボックスを選択して、プロバイダのデータを入力できるようにします。このボックスを選択するまで、すべてのボックスはグレー表示になっています。
プルダウン・リストから「プロバイダ・タイプ」を選択し、選択したプロバイダに該当するデータを入力します(必要なデータは、選択したタイプによって異なります)。
プルダウン・リストから「認証レベル」を選択します。
必要に応じ、ページの下部にある「追加」、「編集」および「削除」を使用してプロバイダの「カスタム・プロパティ」を管理します。
完了したら、「OK」をクリックして、入力したデータを保存します。
「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>
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ソリューションと統合している場合にのみ使用できます。
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>の例を参照してください。
検索フィルタで使用するOracle Internet Directoryの属性は、索引を作成したうえでカタログ化する必要があります。索引作成やカタログ化は通常は必須ではありませんが、OPSS関連の属性の場合は必須です。
本番環境では、ポリシー・ストアの再関連付けが完了してから属性の索引作成とカタログ化を実行することをお薦めします。
属性のカタログの管理と属性の索引が作成済であることの確認の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項を参照してください。
次に示す構文を持つコマンドldapmodify
を使用して、LDIFファイルで指定した属性に索引を作成することもできます。
Oracle Directory Services Managerを使用して新規属性に索引を追加する方法に関する項
Oracle Directory Services Managerを使用して既存属性に索引を追加する方法に関する項
Oracle Directory Services Managerを使用して属性から索引を削除する方法に関する項
Oracle Directory Services Managerを使用して、データを格納済の属性に索引を作成する方法に関する項
カタログを使用して既存属性に索引を作成する方法と索引を削除する方法に関する項
>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>
たとえば、次のサンプルLDIFファイルで前述のコマンドを使用して、createtimestamp
属性とmodifytimestamp
属性をカタログ化できます。
dn: cn=catalogs changetype: modify add: orclindexedattribute orclindexedattribute: modifytimestamp orclindexedattribute: createtimestamp
次のOracle Internet Directoryの各属性には索引を作成する必要があります。
orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee
属性のカタログ化が必要な場合の注意事項は、第L.18項「ポリシー・ストアでの属性照合時の検索の失敗」を参照してください。