| Oracle Containers for J2EE構成および管理ガイド 10g（10.1.3.5.0） B56030-01 |
|
 戻る |
 次へ |
この章では、OC4JインスタンスにデプロイされたWebアプリケーションにアクセスできるように、追加Webサイトを構成する方法について説明します。また、HTTPSを使用して、クライアントとOC4Jの間でSecure Socket Layer（SSL）通信を利用するセキュアなWebサイトを構成および有効化する方法についても説明します。
この章の内容は次のとおりです。
OC4Jでは、OC4Jインスタンスにデプロイされたアプリケーションに送信されるWebリクエストは、Webサイトで受信されます。Webサイトとは、特定のプロトコルおよびポート（またはポートの範囲）でリクエストを受け入れるように構成されたリスナーです。OC4Jインスタンスにデプロイされた各Webモジュールは、そのアクセスに使用されるWebサイトにバインドする必要があります。このバインディングは通常、アプリケーション・デプロイ・プロセスの一環として実行されます。
デフォルトWebサイトは、インストール時に各OC4Jインスタンス内に作成されます。デフォルトWebサイトの構成は、構成ファイルdefault-web-site.xmlに定義されます。このファイルはORACLE_HOME/j2ee/instance/configディレクトリにデフォルトでインストールされます。Webサイトの構成の概要は、「Webサイト接続データの構成」を参照してください。
スタンドアロンOC4J
スタンドアロンOC4J構成では、デフォルトWebサイトは、HTTPリクエストを特定のポート（デフォルトでは8888）で直接受信するように構成されます。あるいは、セキュアなHTTPSリクエストを受信するようにこのサイトを構成できます。
単一のOPMN管理OC4Jインスタンス
単一のOPMN管理OC4Jインストールでは、デフォルトWebサイトは、同様にHTTPまたはHTTPSリクエストを直接受信するように構成できます。特定のリスナー・ポートをdefault-web-site.xmlに指定するか、ポートの範囲をOPMN構成ファイル（opmn.xml）に設定できます。詳細は、「OPMN管理OC4JインスタンスでのWebサイト・データの構成」を参照してください。
複数のOPMN管理OC4Jインスタンス
2つ以上のOPMN管理OC4Jインスタンスのクラスタでは、デフォルトWebサイトは、Apache JServ Protocol（AJP）を介してOracle HTTP Serverから転送されたリクエストを受信するように構成されます。
あるいは、セキュアなAJPSリクエストを受信するようにこのサイトを構成できます。特定のリスナー・ポートを指定するか、ポートの範囲をOPMN構成ファイルに設定できます。OPMN構成の詳細は、「OPMN管理OC4JインスタンスでのWebサイト・データの構成」を参照してください。
|
注意: 現行リリースでは、OC4Jインスタンスでサポートされているのは一度に1つのAJP Webサイトのみです。Oracle Application ServerでAJPおよびAJPSの両方を使用する場合は、それらを異なるOC4Jインスタンスに構成し、2つのOracle HTTP Server（OHS）インスタンスを使用する必要があります。1つはAJPリスクエストのルーティング用で、もう1つはAJPSリクエストのルーティング用です。 |
デフォルト・サイトの他に、必要に応じて、新しいWebサイトを各OC4Jインスタンスで構成できます。（1つのWebサイトは一度に複数のプロトコルでリスニングできません。）次のいずれかの理由で、新しいWebサイトの作成が必要になる場合があります。
管理アクセスと一般的なWebアクセスの分離
デフォルトでは、Application Server Controlのアプリケーションは、デフォルトWebサイトから/emコンテキストを介してアクセスされます。しかし、必要に応じてApplication Server Controlのアプリケーション専用に新しいWebサイトを作成し、管理アクセスと一般的なアプリケーション・アクセスを切り分けることができます。
セキュアなWebサイトと非セキュアなWebサイトの利用
SSLを利用してセキュアな接続を作成するようにデフォルトWebサイトを構成できます。あるいは、追加サイトを作成し、セキュアな接続を必要とするWebアプリケーションにバインドすることもできます。
追加Webサイトの作成および構成の詳細は、「OC4JでのWebサイトの新規作成」を参照してください。
次の各項で説明するように、Webサイトで使用されるプロトコルおよびリスナー・ポートは、スタンドアロンOC4J環境とOracle Application Server環境では構成方法が異なります。
スタンドアロンOC4Jインストールでは、Webサイトで使用されるプロトコルおよびリスナー・ポートを対応する*-web-site.xml構成ファイルに明示的に定義する必要があります。これらのファイルの概要は、「Webサイト構成ファイルの作成」を参照してください。
デフォルトWebサイトは、デフォルトでポート8888でHTTPプロトコルを介して受信されるリクエストをリスニングするように構成されます。
Oracle Application Serverインストールでは、Oracle Process Manager and Notification Server（OPMN）を使用してOC4Jインスタンスを管理しますが、OPMNを使用するとWebサイトのプロトコルおよびポートの構成を効率的に管理できます。OPMNは、起動時に指定された範囲の最小値から始まるポート値を選択し、この値を1ずつ増やしながら空きポートを見つけます。この方法でOPMNがポートの範囲から選択できるようにすると、OC4Jプロセス間で発生する可能性がある競合を回避できます。
Application Server Controlやopmnctlコマンドを使用して、またはopmn.xmlファイルで、OC4Jポートの範囲を変更できます。
Application Server Controlを使用してポート範囲を変更するには、次のようにします。
「クラスタ・トポロジ」ページで、「ランタイム・ポート」をクリックします。
変更するポートの「ポートの構成」アイコンをクリックします。
「サーバー・プロパティ」ページの「ポート」セクションで、変更するポートのポート範囲を変更します。
「適用」をクリックします。
「クラスタ・トポロジ」ページに移動して、変更したOC4Jインスタンスを選択し、「再起動」をクリックします。
「確認」ページで、「はい」をクリックします。
このモデルでは、Webサイトが使用するプロトコルは、OPMN構成ファイルopmn.xmlでWebサイトに対して定義された<port>要素内に指定されます。この要素内には、Webサイトが使用するリスナー・ポートの範囲を指定することもできます。
|
注意: opmnctlコマンドライン・ツールには、OC4Jインスタンスのopmn.xmlファイルに定義された特定のWebサイトに対する<port>要素の更新に使用できるコマンドが用意されています。
使用方法は、「opmnctlによるWebサイトの構成」を参照してください。 |
opmn.xmlに指定されたプロトコルおよびポートの値は、対応するWebサイト構成ファイルに設定された対応する値に優先します。Oracle Application Server環境では、OPMNを使用してWebサイト・プロトコルおよびポート設定を管理する必要はありません。これらの値をopmn.xmlに設定せず、かわりに適切なWebサイト構成ファイルに直接値を設定できます。
<port>要素はopmn.xml構成ファイルに定義されます。このファイルは、ORACLE_HOME/opmn/confディレクトリにあります。この要素の構文は次のとおりです。
<port id="webSiteName" protocol="http|https|ajp|ajps" range="startPort-endPort"/>
表13-1に、<port>要素の属性を示します。
表13-1 <port>要素の属性
| 属性 | 説明 |
|---|---|
|
|
必須。Webサイトの名前を定義します。これは、Webサイト構成ファイルの名前から |
|
protocol |
任意。Webサイトがリクエストの受信に使用するプロトコルを指定します。有効値は次のとおりです。
Oracle Application Serverで |
|
|
任意。OPMNによる割当てに使用できるポートの範囲の開始ポートと終了ポートを指定します。 使用されるデフォルトのリスナー・ポートの範囲は次のとおりです。
開始ポートと終了ポートを同じポート番号に設定することで、範囲のかわりに単一のポートを指定できます。
Oracle Application Serverで |
通信プロトコルを定義する<port>要素はすべて、OC4Jインスタンスを定義する<process-type>要素内に設定します。<process-type>要素は、<ias-component>要素のサブ要素（id属性はdefault_group）です。
たとえば、次の例の<port>要素は、ポート12501〜12600でAJPリクエストをリスニングするように、OC4J homeインスタンスのデフォルトWebサイトを構成します。
<ias-component id="default_group">
<process-type id="home" module-id="OC4J" status="enabled">
...
<port id="default-web-site" protocol="ajp" range="12501-12600"/>
<port id="rmi" range="12401-12500">
<port id="jms" range="12601-12700">
<process-set id="default" numprocs="1"/>
</process-type>
</ias-component>
|
注意: opmn.xmlファイルの変更を有効にするには、リロードする必要があります。対象となるノードで次のコマンドを実行し、opmn.xmlをリロードします。
opmnctl reload このコマンドは、OPMN管理コンポーネント（Oracle HTTP Server、OC4Jおよびデプロイ済アプリケーションなど）には影響を与えません。 |
OPMNコマンドライン・ツールopmnctlには、config portコマンドが用意されています。このコマンドを使用すると、opmn.xmlに定義されるWebサイトの構成を指定、更新または削除できます。
opmnctlツールは、各ノードのORACLE_HOME/opmn/binディレクトリにインストールされています。このツールは各ノードで個別に実行する必要があり、そのノードのopmn.xmlファイルのみが更新されます。
opnm.xmlでのWebサイト構成データの挿入または更新
config port updateコマンドは、指定されたデータを新規または既存の<port>要素に設定します。このコマンドの構文は次のとおりです。
opmnctl config port update ias-component=componentName process-type=instanceName portid=webSiteName [range=startPort-endPort] [protocol=http|https|ajp|ajps]
たとえば、OC4JインスタンスのデフォルトWebサイトは、現在、HTTPリクエストをリスニングするように構成されています。次のコマンドは、デフォルトWebサイトの構成を、Oracle HTTP ServerからのApache JServ Protocol（AJP）リクエストを受信して応答するように変更します。
opmnctl config port update ias-component=default_group process-type=home portid=default-web-site protocol=ajp opmnctl reload
opmnctl reloadコマンドは、OC4Jランタイムに更新されたopmn.xmlファイルをリロードするために起動されます。
Webサイトのプロトコルを変更しても、ポート範囲は、指定したプロトコルのデフォルトの範囲にはリセットされません。ポート範囲を変更するには、config port updateコマンドでrangeパラメータを使用します。
Oracle Application ServerでAJPおよびAJPSの両方を使用する場合は、それらを異なるOC4Jインスタンスに構成し、2つのOracle HTTP Server（OHS）インスタンスを使用する必要があります。1つはAJPリスクエストのルーティング用で、もう1つはAJPSリクエストのルーティング用です。
opnm.xmlからのWebサイト構成データの削除
deleteコマンドは、指定されたWebサイトに対して定義された<port>要素を削除します。構文は次のとおりです。
opmnctl config port delete ias-component=componentName process-type=instanceName portid=webSiteName
たとえば、次の例ではデフォルトWebサイトに対して定義された<port>要素をopmn.xmlから削除しています。
opmnctl config port update ias-component=default_group process-type=home
portid=default-web-site
opmnctl reload
表13-2に、opmnctl config portコマンドラインで設定できるオプションを示します。
表13-2 opmnctl config portのオプション
| オプション | 説明 |
|---|---|
|
|
|
|
|
更新するOC4Jインスタンスの識別子（ |
|
|
Webサイトの名前に設定します。これは、Webサイト構成ファイルの名前から |
|
|
Webサイトがリクエストの受信に使用するプロトコルを指定します。
Webサイトのプロトコルを変更しても、ポート範囲は、指定したプロトコルのデフォルトの範囲にはリセットされません。ポート範囲を変更するには、 |
|
|
OPMNによる割当てに使用できるポートの範囲の開始ポートと終了ポートを設定します。 デフォルトのポートの範囲は次のとおりです。
開始ポートと終了ポートを同じポート番号に設定することで、範囲のかわりに単一のポートを指定できます。 Webサイトのプロトコルを変更しても、ポート範囲は、指定したプロトコルのデフォルトの範囲にはリセットされません。ポート範囲を変更するには、 |
OC4Jインスタンス内での新しいWebサイトの有効化は、基本的に2段階（必要に応じて3段階）プロセスです。
OC4Jがインストールされたディレクトリ構造内でWebサイトのXML構成ファイルを作成します。
新しいWebサイト構成ファイルへの参照をOC4J構成ファイルserver.xmlに追加します。
OPMN管理OC4Jインスタンスの場合は、Webサイトのプロトコルおよびポートの範囲を定義する<port>要素をopmn.xmlに追加します。
これらの手順を完了すると、Webサイトはアプリケーションとバインドできるようになります。次の各項では、Webサイトの構成について詳しく説明します。
Webサイト構成ファイルに定義される主な情報には、次のものがあります。
サイトへのアクセスに使用されるURLの最後に追加される、サイトにバインドされる各アプリケーションのWebコンテキスト（/emなど）。
サイトで使用されるプロトコル。OPMN管理の環境では、この値はopmn.xmlに指定されたプロトコルによって上書きされます。
サイトがリスニングするポート。OPMN管理の環境では、この値はopmn.xmlに指定されたポートの範囲によって上書きされます。
サイトへのユーザー・アクセスを追跡する、アクセス・ログ・ファイルの場所。
新しい構成ファイルを作成する最も簡単な方法は、デフォルトWebサイトの構成ファイルdefault-web-site.xmlのコピーを作成することです。このファイルは、ORACLE_HOME/j2ee/instance/configディレクトリにあります。ファイルには、次の規則に従って名前を付けます。
webSiteName-web-site.xml
一般的な構成ファイルには、次の情報を指定する属性が含まれる<web-site>ルート要素を指定します。
host: このWebサイトのホストをDNSホスト名またはIPアドレスのいずれかで指定します。サーバーが複数のIPアドレスを保持する場合、ALL設定を使用してすべてのIPアドレスをリスニングできます。
port: Webサイトのリスナー・ポート。
display-name: Webサイトの表示用の名前。
virtual-hosts: このWebサイトにバインドされる追加ドメイン。
また、<web-site>要素には通常、次のサブ要素が含まれます。
<default-web-app>要素。WebサイトからデフォルトでアクセスされるWebアプリケーションを定義します。単一のアプリケーションがWebサイトにバインドされる場合（Application Server Controlなど）、そのアプリケーションをこの要素内に指定します。
Webサイトにバインドされる各Webモジュールに対する1つ以上の<web-app>サブ要素。これらの要素は、各アプリケーションがWebサイトにバインドされるときにOC4Jによって追加されますが、必要に応じて手動でファイルに追加することができます。少なくとも、各<web-app>要素には次の属性があります。
application属性。Webモジュールが属するJ2EEアプリケーションの名前を指定します（.ear拡張子を除いたEARファイル名と同じです）。
name属性。Webモジュールの名前を指定します（.war拡張子を除いたWARファイル名と同じです）。
root属性。Webモジュールのバインド先となる、このWebサイトのコンテキスト・パスまたはコンテキスト・ルートを指定します。
<access-log>要素。サイトに送信されるリクエストが記録されるログ・ファイルを指定します。
たとえば、Application Server Controlへの管理アクセスを提供するためにのみ使用されるWebサイトを定義する、ascontrol-web-site.xmlという構成ファイルを作成するとします。このファイルの<web-site>ルート要素には、次に示すように、必須構成データがすべて含まれます。
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/
web-site-10_0.xsd" port="1810"
display-name="Application Server Control Web Site">
<default-web-app application="ascontrol" name="ascontrol" access-log="true" />
<access-log path="../log/ascontrol-web-access.log" />
</web-site>
この要素の構造の詳細は、<web-site>要素の説明を参照してください。
|
注意: この例で示すように、Application Server Controlのみが使用するWebサイトを作成する場合、ORACLE_HOME/j2ee/からアクセスされるOC4JホームページのApplication Server Controlの起動リンクを正しいURLで更新することも必要です。 |
すべてのWebサイト構成ファイルの場所は、J2EE_HOME/configディレクトリにあるOC4J構成ファイルserver.xmlの<web-site>要素で参照する必要があります。この宣言がserver.xmlにないと、アプリケーションはWebサイトにバインドできません。
各<web-site>要素は、サンプルのserver.xmlの次のエントリに示すように、対応するWebサイトのXMLファイルのパスおよびファイル名を指定します。
<application-server ... >
<web-site path="./default-web-site.xml" />
<web-site path="./ascontrol-web-site.xml" />
</application-server>
この例では、すべてのWebサイト構成ファイルの場所は、server.xmlの場所に対して相対的です。
|
注意: OC4Jポーリングが無効になっている場合、server.xmlに対する変更を有効にするには、OC4Jを再起動する必要があります。 |
Oracle Application Serverインストールでは、Oracle Process Manager and Notification Server （OPMN）を使用してOC4Jインスタンスを管理しますが、OPMNを使用するとWebサイトのプロトコルおよびポートの構成を効率的に管理できます。opmnctl config portコマンドを使用して、Webサイトの新しい<port>要素をopmn.xmlのOC4Jインスタンス定義に追加します。
次の例では、ascontrol Webサイトのプロトコル（HTTP）およびポート（1810）を設定しています。
opmnctl config port update ias-component="default_group" id="ascontrol-web-site" protocol="http" range="1810"
次の例のコマンドは、新しい<port>要素をホスト・マシンにあるopmn.xmlファイルのhome OC4Jインスタンス定義に追加します。これで、このOC4Jインスタンスは2つのWebサイト、すなわちデフォルト・サイトと新しいascontrolサイトを保持するように構成されます。
<ias-component id="default_group">
<process-type id="home" module-id="OC4J" status="enabled">
...
<port id="default-web-site" protocol="ajp" range="12501-12600"/>
<port id="ascontrol-web-site" protocol="http" range="1810"/>
<port id="rmi" range="12401-12500">
<port id="jms" range="12601-12700">
<process-set id="default" numprocs="1"/>
</process-type>
</ias-component>
Webアプリケーションを共有するということは、セッション、サーブレット・インスタンス、コンテキスト値を含め、アプリケーションを構成するすべてのものを共有するということを暗に示しています。
このモードの一般的な用途は、基本的にWebアプリケーションを2つの異なるWebサイトにバインドして、同じコンテキスト・パス上のHTTPサイトとHTTPSサイト間でそのWebアプリケーションを共有することです。これにより、リクエストのすべての情報を暗号化する必要がなく、機密情報のみを必要に応じて暗号化するため、パフォーマンスは向上します。
もう1つの利点は、セッションの追跡にSSL証明書ではなくCookieが使用されることです。SSL証明書は、追跡する際に各証明書を格納するために50KBを使用するので、セッションがタイムアウトする前に、セッションに対してメモリー不足の問題が発生する場合があります。Cookieの使用により、Webアプリケーションの安全性が低下する可能性はありますが、一部のブラウザでは適切にサポートされていない、SSLセッション・タイムアウトなどの問題に対処するためには必要です。
アプリケーションのバインド先となる各Webサイトを定義する*-web-site.xmlファイルで、<web-app>要素のshared属性をtrueに設定すると、アプリケーションを共有として設定できます。この属性は、デフォルトではfalseです。
たとえば、サンプルのpetstoreアプリケーションをデフォルトのOC4J Webサイト（ポート8888でリスニング）と新しいセキュアなWebサイト（ポート4443でリスニング）の間で共有するには、各Webサイト構成ファイルで次の<web-app>要素を追加または変更します。この構成により、アプリケーションはHTTP接続とHTTPS接続の両方を受け入れることができるようになります。
default-web-site.xmlの<web-app>エントリ:
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/
web-site-10_0.xsd" port="8888" display-name="OC4J 10g (10.1.3) HTTP Web Site">
<web-app application="petstore" name="petstore" load-on-startup="true"
root="/petstore" shared="true" access-log="true"/>
<access-log path="../log/http-web-access.log" />
</web-site>
secure-web-site.xmlの同様のエントリ:
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/ web-site-10_0.xsd" port="4443" secure ="true" display-name="My Secure Web Site"> <web-app application="petstore" name="petstore" load-on-startup="true" root="/petstore" shared="true" access-log="true/> <access-log path="../log/secure-web-access.log" /> <ssl-config keystore="../../server.keystore" keystore-password="welcome" provider="com.sun.net.ssl.internal.ssl.Provider" /> </web-site>
Cookieドメインを特定の値に設定できます。これにより、Cookieの作成時にドメインは特定の値に設定され、CookieはWebブラウザによってドメイン内のWebサイトに送信できるようになります。
ドメインが指定されない場合、ブラウザは、site1.acme.comなどの完全修飾されたサーバー名のドメインにデフォルトで設定されます。この場合、ブラウザはsite2.acme.comにCookieを転送できません。しかし、Cookieドメインが明示的にacme.comに設定される場合、Cookieはいずれのサーバーにも送信できます。
アプリケーションのJ2EE標準orion-web.xmlファイルの<session-tracking>要素にcookie-domain属性を設定します。cookie-domain属性には、指定したドメイン名のコンポーネントが2つ以上あるDNSドメインが含まれます。次に例を示します。
<session-tracking cookie-domain=".oracle.com" />
OC4Jでは、HTTPSおよびAJPSを使用して、クライアントとOC4Jの間のSecure Socket Layer（SSL）通信をサポートします。SSLを利用してセキュアな接続を作成するように、デフォルトWebサイトの構成ファイルを変更できます。あるいは、追加サイトを作成し、セキュアな接続を必要とするWebアプリケーションにバインドすることもできます。
SSLの鍵および証明書の詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。
この項の内容は次のとおりです。
次の例に示すように、<web-site>要素の下に適切なSSL設定を指定します。
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/ web-site-10_0.xsd" port="4443" secure="true" display-name="My Secure Web Site"> <access-log path="../log/secure-web-access.log" /> <ssl-config keystore="../../server.keystore" keystore-password="welcome" provider="com.sun.net.ssl.internal.ssl.Provider" /> </web-site>
太字で示した<web-site>への追加に注意してください。
値をtrueに設定したsecure属性を追加します。設定secure="true"は、HTTPプロトコルでSSLソケットを使用することを指定します。
port属性を使用可能なポートに設定します。SSLポートのデフォルトは443です。この例では、port属性は4443に設定されています。
<ssl-config>要素を追加します。secureフラグをtrueに設定するときは常に、この要素が必要です。この要素は、次の属性および要素を取ります。
任意のfactory属性。アプリケーションでJSSEを使用しない場合に使用するサード・パーティのSSLServerSocketFactory実装を指定するために使用します。
アプリケーションでサード・パーティのSSLServerSocketFactory実装を使用する場合、<ssl-config>の<property>サブ要素を使用してパラメータをファクトリに送信できます。
|
注意: factory属性およびそのパラメータは推奨されません。 |
keystoreおよびkeystore-password属性。キーストアのディレクトリ・パスおよびパスワードを指定します。指定されるキーストアには、HTTPSによるOC4Jへの接続を認可されたクライアントの証明書が含まれている必要があります。keystoreの値は、絶対ディレクトリ・パスまたは相対ディレクトリ・パスのいずれかを示し、ファイル名が含まれます。
任意のprovider属性。使用するセキュリティ・プロバイダを指定するために使用できます。
デフォルトでは、Sun社の実装（com.sun.net.ssl.internal.ssl.Provider）が使用されます。（この例ではデフォルトの実装が示されていますが、これは暗黙であるため指定する必要はありません。）
1つ以上の<property>要素。SSLServerSocketFactoryに渡すパラメータが含まれます。各要素には、name属性およびvalue属性が含まれ、名前/値ペアとしてパラメータを指定できます。
|
注意: SSLServerSocketFactoryのパラメータは非推奨です。 |
Webサイト構成ファイルが用意できたら、J2EE_HOME/configディレクトリにあるOC4J構成ファイルserver.xmlを参照する<web-site>要素を追加します。server.xmlにこの記述がないと、アプリケーションはWebサイトにバインドできません。次に例を示します。
<application-server ... >
<web-site path="./default-web-site.xml" />
<web-site path="./mycustom-web-site.xml" />
<web-site path="./secure-web-site.xml" />
</application-server>
構成が完了すると、OC4Jは一方のポートでSSL HTTPリクエストを、もう一方のポートで非SSL HTTPリクエストをリスニングします。server.xml構成ファイルで該当する*-web-site.xmlをコメントアウトすると、SSLリクエストまたは非SSLリクエストのいずれかを無効にできます。
<!-- <web-site path="./secure-web-site.xml" /> commented out to remove SSL -->
<web-site>、<web-app>および<session-tracking>要素の要素および属性の詳細は、『Oracle Containers for J2EEサーブレット開発者ガイド』を参照してください。
<ssl-config>要素のneeds-client-auth属性をtrueに設定すると、サーバーによるクライアントの認証を要求できます。次に例を示します。
<web-site ... secure="true" ... > <ssl-config keystore="../../server.keystore" keystore-password="welcome" needs-client-auth="true" /> </web-site>
この手順では、OC4Jがセキュアな通信のためにアイデンティティに応じてクライアント・エンティティを受け入れるか拒否するモードを設定します。needs-client-auth属性は、接続に関するクライアントの証明連鎖を要求するようにOC4Jに指示します。クライアントのルート証明書が認識されると、そのクライアントは受け入れられます。
<ssl-config>要素に指定されるキーストアには、HTTPSによるOC4Jへの接続を認可されたクライアントの証明書が含まれている必要があります。
OC4Jでは、クライアント認証モードをサポートします。このモードでは、サーバーはクライアントと通信する前に、クライアントからの認証を明示的に要求します。この場合、クライアントには独自の証明書が必要です。クライアントは、証明書およびルート証明書で終わる証明連鎖を送信して自己認証を行います。OC4Jは、クライアントに至る信頼の連鎖を確立する際に、指定されたリストからルート証明書のみを受け入れるように構成できます。
OC4Jが信頼する証明書は、トラスト・ポイントと呼ばれます。これは、OC4Jがクライアントからの連鎖で検出する最初の証明書であり、独自のキーストア内のものと一致します。この信頼関係を構成するには、次の3つの方法があります。
クライアント証明書がキーストアにあること。
クライアントの連鎖に含まれる中間認証局の証明書の1つがキーストアにあること。
クライアントの連鎖に含まれるルート認証局の証明書がキーストアにあること。
OC4Jは、偽造された証明書を防ぐために、トラスト・ポイントを含む証明連鎖全体が有効であるかどうかを検証します。
needs-client-auth属性を使用してクライアント認証を要求するには、次のようにします。
クライアントの連鎖のうちトラスト・ポイントとする証明書を決定します。このトラスト・ポイントを使用して証明書の発行を制御すること、または認証局を発行者として信頼することを確認します。
クライアントの証明書の認証用に、中間証明書またはルート証明書をトラスト・ポイントとしてサーバーのキーストアにインポートします。
OC4Jが特定のトラスト・ポイントにアクセスしないようにする場合は、これらのトラスト・ポイントがキーストアにないことを確認します。
前述の手順を実行して、サーバーにインストールされた中間証明書またはルート証明書を含むクライアント証明書を作成します。別の認証局を信頼する場合は、その認証局からの証明書を取得します。
証明書をクライアント上にあるファイルに保存します。
クライアントがHTTPS接続を開始するときに、証明書を指定します。
クライアントがブラウザの場合は、クライアントのブラウザのセキュリティ領域内で証明書を設定します。
クライアントがJavaクライアントの場合は、HTTPS接続の開始時に、クライアント証明書および証明連鎖をプログラムで指定する必要があります。
Webサイトは、OC4Jインスタンスで構成されると、デフォルトで使用できるようになります。しかし、Application Server Controlには、「管理」→「J2EE Webサイト」ページから個々のWebサイトを停止および起動する機能があります。これらのページには、各Webサイトの構成も表示され、各サイトにバインドされているWebモジュールにアクセスできます。
|
注意: ascontrol-web-siteはApplication Server Controlで使用されるため、ユーザー・インタフェースを介して停止することはできません。 |
Application Server Controlで「管理」リンクをクリックします。
「管理タスク」→「プロパティ」の下の「J2EE Webサイト」アイコンをクリックします。OC4Jインスタンスで構成されたWebサイトがページにリスト表示されます。
目的のWebサイトの名前をクリックします。
OC4JにはWebサイトごとにアクセス・ログを生成する機能があり、クライアントによってWebサイトに送信されたリクエストを記録します。
アクセス・ログは、テキストベースのログ・ファイルまたはOracle Diagnostic Logging（ODL）ファイルとして生成できます。これらのファイルは、Application Server Controlを使用して表示できるXML形式で生成されます。Webサイトに対して構成できるアクセス・ロギングのタイプは1つのみです。
アクセス・ロギングは、Webサイトに対して、そのWebサイト構成ファイル（*-web-site.xml）で<access-log>または<odl-access-log>要素を使用して構成されます。どちらの要素も構成ファイルに指定されていない場合、アクセス・ログはそのWebサイトに対して生成されません。
この項の内容は次のとおりです。
テキストベースのアクセス・ロギングは、対応するWebサイトの構成ファイル（*-web-site.xml）の<web-site>ルート要素の<access-log>サブ要素を使用して構成されます。
|
注意: このロギング形式はログの循環をサポートしないため、テキストベースのアクセス・ログ・ファイルの監視は重要です。チェックしないままにしておくと、アクセス・ログ・ファイルのサイズは増大し続け、ディスク超過が発生する可能性があります。 |
この<access-log>要素には次の属性があります。
path: アクセス・ログのパスおよびファイル名を指定します。これは唯一の必須属性です。単独で指定するとアクセス・ログが生成されます。
default-web-site.xmlの次のエントリに示すように、このパスは、Application Server Controlを使用してログを表示できるように、ORACLE_HOME/j2ee/instance/configディレクトリに対して相対的である必要があります。
<access-log path="../log/default-web-access.log" />
format: 複数のサポートされる変数（ログ・エントリの先頭に付加される情報となる）を1つ以上を指定します。サポートされる変数は、$time、$timeUsed、$request、$ip、$host、$path、$size、$method、$protocol、$user、$status、$referer、$agent、$cookie:[name]、$header:[name]および$mimeです。変数の間には、ログ・メッセージの値の間に表示するセパレータを入力できます。デフォルト設定は次のとおりです。
"$ip - $user - [$time] '$request' $status $size"
このデフォルト構成は、次のようなログ・メッセージになります（2番目のメッセージは2行目に折り返されています）。
148.87.1.180 - - [17/Nov/2004:10:23:18 -0800] 'GET / HTTP/1.1' 200 2929 148.87.1.180 - - [17/Nov/2004:10:23:53 -0800] 'GET /webservices/statefulTest HTTP/1.1' 200 301
この例では、ユーザーはNULL、時刻は（format設定に指定された）大カッコで囲まれ、リクエストは（指定された）一重引用符で囲まれ、最初のメッセージのステータスおよびサイズはそれぞれ200および2929です。
$timeUsed変数により、HTTPトランザクションの処理にかかった時間が秒単位で計測されます。この変数の名前では大/小文字が区別されます。
split: 新しいアクセス・ログを開始する頻度を指定します。サポートされる値は、none（デフォルト値のneverと同じ）、hour、day、weekおよびmonthです。splitを指定する場合、suffix属性（次の項目で説明）を使用して、ファイル名の最後に追加するタイムスタンプ・データを指定できます。
suffix: split属性が指定されている場合、ログのベース・ファイル名の最後に追加するタイムスタンプ情報を指定します。
デフォルトのsuffix値は-yyyy-mm-ddです。
たとえば、デフォルトのsuffix値を使用する、splitが指定された次の<access-log>要素を考えてみます。
<access-log path="../log/mysite-web-access.log" split="day" />
生成されるログ・ファイルには、次のような名前が付けられます。
mysite-web-access-2004-11-17.log
使用される形式はjava.text.SimpleDateFormatの形式で、suffix設定で使用される記号は、そのクラスの記号表記に従います。SimpleDateFormatのドキュメントで説明されているように、大/小文字は区別されます。SimpleDateFormatと、そこで使用される書式記号の詳細は、次のURLでSun社の最新のJavadocを参照してください。
http://java.sun.com/j2se/
default-web-site.xmlの次のエントリは、default-web-access.logという名前のファイルを生成します。
<web-site> ... <access-log path="../log/default-web-access.log" /> </web-site>
ファイルは、使用しているOC4Jインストールに応じて、次の場所に生成されます。
スタンドアロンOC4J:
ログ・ファイルは、ORACLE_HOME/j2ee/home/log/に生成されます。
Oracle Application Server:
ファイルは、ORACLE_HOME/j2ee/instance/application-deployments/log/instance_default_group_1というOC4Jインスタンス固有のディレクトリに生成されます。
アクセス・ログのテキスト・ファイルは、Application Server Controlで「ログ」リンクをクリックすると表示できます。テキストベースのログ・ファイルは、「ログ・ファイル」ページでは.log拡張子によって識別されます。
Application Server Controlのページの一番下にある「ログ」リンクをクリックします。
「OC4J」を開きます。
「<instanceName>」を開きます。デフォルトのインスタンス名はhomeです。
ODLフレームワークでは、ログ・ファイルはXML文書形式で作成されます。ODLアクセス・ロギングの主な利点は、テキストベースのロギングとは異なり、ログ・ファイルの循環をサポートしていることです。
ODLアクセス・ロギングは、Webサイトの構成ファイルの<web-site>ルート要素の<odl-access-log>サブ要素を使用して構成されます。この要素には次の属性があります。これらの属性はすべて必須です。
path: Webサイトのlog.xmlファイルが生成されるディレクトリへのパス。
このパスは、Application Server Controlを使用してログ・ファイルを表示できるように、*-web-site.xml構成ファイルに対して相対的である必要があります。
より簡単に管理するには、Webサイトの名前をパスに含めます。
max-file-size: 個々のログ・ファイルに対して許容される最大サイズ（KB単位）。この制限に達すると、新しいログ・ファイルが生成されます。
max-directory-size: ログ・ファイル・ディレクトリに対して許容される最大サイズ（KB単位）を設定します。この制限を超えると、最も古いログ・ファイルから消去されます。
ディレクトリの最大サイズに達するまで、log.xmlという新しいファイルがpath属性に指定されたディレクトリ内に生成されます。各ログ・ファイルは、属性に指定された最大サイズ以下になります。
たとえば、default-web-site.xmlの次のエントリは、log.xmlファイルを生成します。また、ORACLE_HOME/j2ee/home/log/内の/default-web-accessディレクトリで、ログ・ファイルの最大値を1,000KBに、ディレクトリの最大値を10,000KBに設定します。
<web-site>
...
<odl-access-log path="../log/default-web-access/" max-file-size="1000"
max-directory-size="10000" />
</web-site>
ログ・ファイルは、使用しているOC4Jインストールに応じて、次の場所に生成されます。
スタンドアロンOC4J:
ログ・ファイルは、ORACLE_HOME/j2ee/home/log/default-web-access/に生成されます。
Oracle Application Server:
ファイルは、ORACLE_HOME/j2ee/instance/application-deployments/log/instance_default_group_1/default-web-accessというOC4Jインスタンス固有のディレクトリに生成されます。
ODLアクセス・ログの詳細は、「ODLログ・ファイルの管理」を参照してください。
ODL形式のログ・ファイルは、Application Server Controlで「ログ」リンクをクリックすると表示でき、管理者は、一元管理された場所からOC4J内で稼働しているすべてのコンポーネントおよびアプリケーションによって生成されたロギング出力を集計および表示できます。
ODLログ・ファイルは、「ログ・ファイル」ページでは.xml拡張子で識別されます。
Application Server Controlのページの一番下にある「ログ」リンクをクリックします。
「OC4J」を開きます。
「<instanceName>」を開きます。スタンドアロンOC4JとOASのいずれでも、デフォルト・インスタンス名はhomeです。
デフォルトWebサイト・ノードを開きます。
診断メッセージ・ログを開きます。
<access-log>または<odl-access-log>要素がWebサイト構成ファイルに定義されている場合、アクセス・ロギングは、Webサイトにバインドされたアプリケーション内のWebモジュールに対してデフォルトで有効になりません。OC4J 10g 10.1.3.1.0では、構成ファイルのアプリケーション固有の<web-app>要素のaccess-log属性のデフォルト値はfalseです。
しかし、モジュールのaccess-log属性をtrueに設定すると、特定のモジュールに対してアクセス・ロギングを有効にできます。
Webモジュールが大量のリクエストを送信してテキストベースのアクセス・ログ・ファイルが急速に肥大化するような状況では、アクセス・ロギングを無効にしておくことをお薦めします。Webサイト構成ファイルまたはモジュールでaccess-logがtrueに設定されている場合、access-log属性をfalseに設定することでモジュールのアクセス・ロギングを無効化できます。
たとえば、default-web-site.xmlの次のエントリは、defaultアプリケーションのDMS Webコンポーネントに対するアクセス・ロギングを無効にしますが、admin_webモジュールに対するテキストベースのアクセス・ロギングは有効化されます。
<web-site ...> <web-app application="default" name="dms0" root="/dmsoc4j" access-log="false" /> <web-app application="default" name="admin_web" root="/adminoc4j" /> <access-log path="../log/http-web-access.log" access-log="true" /> </web-site>
