ヘッダーをスキップ

Oracle HTTP Server スタンドアロン・デプロイの管理Apache 2.0ベース
10g（10.1.3.1.0）
B31848-02
目次
目次		 索引
索引

戻る 次へ

7 セキュリティの管理

この章では、Oracle HTTP Serverのセキュリティ機能、およびセキュアなWebサイトを設定するための構成情報について説明します。

記載されている内容は、次のとおりです。

7.1 Oracle HTTP Serverのセキュリティの概要

セキュリティ機能は、認証、認可および機密保護という3つのカテゴリに分類できます。Oracle HTTP Serverでは、この3つのカテゴリのすべてをサポートします。Oracle HTTP ServerはApache Web Serverがベースで、そのセキュリティ・インフラストラクチャは、主にApacheモジュールのmod_authとmod_access、およびOracleモジュールのmod_osslとmod_ossoにより提供されています。mod_authはユーザー名とパスワードのペアに基づく認証を提供し、mod_accessはリクエストの特性（ホスト名またはIPアドレスなど）に基づいてサーバーへのアクセスを制御します。mod_osslはSSLを介してX.509クライアント証明書を使用した機密保護と認証を提供し、mod_ossoはWebアプリケーションでシングル・サインオン認証を使用可能にします。

Apacheモデルに基づいて、Oracle HTTP Serverではアクセス制御、認証および認可の各メソッドを提供しています。これらのメソッドは、httpd.confファイルのアクセス制御ディレクティブを使用して構成できます。Oracle HTTP ServerにURLリクエストが着信すると、サーバーのデフォルトと構成パラメータで決定される一連の手順で処理されます。URLリクエストの処理手順は、多くのWebリスナーに共通のモジュール（プラグイン）アーキテクチャを使用して実装されています。

図7-1は、サーバーによるURLリクエストの処理方法を示したものです。このプロセスの各手順は、サーバー・モジュールによりサーバーの構成に応じて処理されます。たとえばBasic認証が使用される場合、図7-1の認証および認可という手順は、mod_authモジュールの処理を示します。

図7-1    Oracle HTTP ServerでのURLリクエストの処理手順


7.2 ユーザーのクラスとその権限

Oracle HTTP Serverはユーザーを認可および認証します。ユーザーは、認可および認証後にサーバー上のリソースにアクセス、またはこれを変更できます。Oracle HTTP Serverを使用してサーバーにアクセスするユーザーの3つのクラスとその権限は、次のとおりです。

7.3 保護されるリソース

Oracle HTTP Serverは、次のようなリソースを保護するように構成されています。

7.4 認証と認可の適用

Oracle HTTP Serverは、ユーザーの認証と認可を2段階で提供します。

7.4.1 ホストベースのアクセス制御

リクエスト処理サイクルの初期にアクセス制御が適用されます。これにより、ホスト名、IPアドレスまたはその他の特性（ブラウザ・タイプなど）に基づいて、後続の処理を禁止できます。このタイプのアクセス制御を設定するには、deny、allowおよびorderディレクティブを使用します。この制限はOracle HTTP Server構成ディレクティブを使用して構成します。例7-1に示すように、<Files>、<Directory>および<Location>コンテナ・ディレクティブを使用し、特定のファイル、ディレクトリまたはURL形式に基づいて制限できます。

例7-1    ホストベースのアクセス制御

<Directory /internalonly/>
  order deny, allow
  deny from all
  allow from 192.168.1.* us.oracle.com
</Directory>

例7-1で、orderディレクティブは、Oracle HTTP Serverがdenyおよびallowディレクティブの条件を読み取る順序を決定します。denyディレクティブは、すべてのリクエストがアクセスを拒否されるようにします。次に、allowディレクティブを使用して、192.168.1.*範囲内の任意のIPアドレスから送信されるリクエストまたはドメイン名us.oracle.comを持つリクエストに対して、ディレクトリ/internalonly/内のファイルへのアクセスが許可されます。ホスト・ベースの認証では、アクセス・ポリシーを明確にするために、allowとdenyの両方を使用するのが一般的な方法です。

ファイル・システム・レベルでオブジェクトを比較する場合は、<Directory>または<Files>を使用する必要があります。URLレベルでオブジェクトを比較する場合は、<Location>を使用する必要があります。

注意

インターネット・アクセスの場合、ホスト名に基づいてアクセスを許可または制限するのは、セキュリティを提供する方法として優れているとはみなされません。ホスト名は簡単にスプーフィング（なりすまし）されるためです。IPアドレスでもこれは同じですが、妨害行為はより難しくなります。ただし、同じリスクを伴わないため、イントラネットのIPアドレス範囲を使用してアクセス制御を設定するのは合理的です。この場合は、ファイアウォールが正しく構成されているものとします。 

7.4.1.1 仮想ホストのアクセス制御

仮想ホストにアクセス制御を設定するには、サーバー構成ファイルhttpd.conf内の仮想ホスト・コンテナの中にIncludeディレクティブを指定します。Includeディレクティブを仮想ホスト・コンテナ内で使用すると、ファイル内に含まれるアクセス制御ポリシーが指定されます。例7-2は、httpd.confファイルからの抜粋です。Includeをこの方法で使用するための構文が示されています。

例7-2    AccessConfigを使用したアクセス制御の設定

...
<VirtualHost ip_address_of_host.some_domain.com>
  ... virtual host directives ...
  Include conf/include.conf
</VirtualHost>

7.4.1.2 ホストベースのアクセス制御のためのmod_accessとmod_setenvifの使用

ホストベースのアクセス制御方法を使用すると、HTTPリクエストの発信元に基づいて制限領域へのアクセスを制御できます。Oracle HTTP Serverではmod_accessとmod_setenvifを使用して、ホストベースのアクセス制御を実行します。mod_accessは、クライアントのホスト名、IPアドレスまたはクライアント・リクエストのその他の特性に基づいてアクセス制御を提供し、mod_setenvifは、リクエストの属性に基づいて環境変数を設定する機能を提供します。これらのモジュールを使用する構成ディレクティブをhttpd.confファイルに入力すると、サーバーでは、ホストのアドレス、名前またはHTTPリクエスト・ヘッダーの内容に基づいて、リクエストを実行あるいは拒否します。

ホストベース・アクセス制御を使用すると、静的なHTMLページ、アプリケーションまたはコンポーネントを保護できます。

Oracle HTTP Serverは、次の4種類のホストベースのアクセス制御方法をサポートします。

これらの方法ではすべて、保護領域へのアクセス権が付与または拒否されるマシンを指定できます。ホストベースのアクセス制御方法のどれを選択するか（複数も可）は、制限されているコンテンツやアプリケーションをどの方法が最も効率的に保護するか、またはどの方法が最も保守しやすいかによって決まります。

7.4.1.2.1 IPアドレスによるアクセス制御

IPアドレスを使用したアクセス制御は、ホストベースのアクセス制御でよく使用される方法です。この方法では、DNS参照を必要としません。DNS参照には時間とシステム・リソースがかかり、サーバーがDNSスプーフィング攻撃を受けやすくなります。

例7-3    IPアドレスによるアクセス制御

<Directory /secure_only/>
  order deny,allow
  deny from all
  allow from 207.175.42.*
</Directory>

例7-3では、207.175.42.*範囲を除く全IPアドレスからのリクエストは、/secure_only/ディレクトリへのアクセスを拒否されます。

7.4.1.2.2 ドメイン名によるアクセス制御

ドメイン名ベースのアクセス制御をIPアドレス・ベースのアクセス制御とともに使用すると、IPアドレスが警告なしで変更される問題が解決します。この2つの方法を組み合せると、IPアドレスが変更される場合でも、排除するドメイン名はアクセスを拒否されるため、サイトの制限領域が保護されます。

ドメイン名ベースとIPアドレス・ベースのアクセス制御を組み合せるには、例7-4に示されている構文を使用します。

例7-4    ドメイン名によるアクセス制御

<Directory /co_backgr/>
  order allow,deny
  allow from all
  # 141.217.24.* is the IP for malicious.cracker.com
  deny from malicious.cracker.com 141.217.24.*
</Directory>

例7-4では、ディレクトリ/co_backgr/に対するリクエストは、ドメイン名malicious.cracker.comまたはIPアドレス範囲141.217.24.*からのリクエストを除いて、すべて受信されます。これは、ドメイン名またはIPアドレスのスプーフィングに対する絶対的な予防措置ではありませんが、malicious.cracker.comがIPアドレスを変更している場合でも、ここからの攻撃に対してサイトを保護します。

7.4.1.2.3 ネットワークまたはネットマスクによるアクセス制御

ネットワークのサブセット（IPアドレスにより指定）に基づいてアクセスを制御できます。この構文を例7-5に示します。

例7-5    ネットワークまたはネットマスクによるアクセス制御

<Directory /payroll/>
  order deny,allow
  deny from all
  allow from 10.1.0.0/255.255.0.0
</Directory>

例7-5では、ネットワークとネットマスクのペアからのアクセスが許可されます。ネットマスクは、IPアドレスをネットワーク、サブネットおよびホスト識別子に分割する方法を示したものです。ネットマスクを使用すると、IPアドレスのホストID部分のみを参照できます。

例7-5のネットマスク255.255.0.0は、クラスBアドレスのデフォルト・ネットマスク設定です。バイナリの1（10進の255）がネットワークIDをマスクし、バイナリの0（ゼロ）（10進のゼロ）が、指定されたIPアドレスのホストIDを保持します。

7.4.1.2.4 環境変数を使用したアクセス制御

アクセス制御には、IPアドレスやドメイン名のかわりに任意の環境変数を使用できます。このタイプのアクセス制御には、BrowserMatchおよびSetEnvIfディレクティブを使用します。

注意

通常、BrowserMatchおよびSetEnvIfはセキュリティ・ポリシーの実装には使用されません。これらは、ブラウザのタイプとバージョンに応じて異なるリクエスト処理を提供するために使用されます。 

BrowserMatchは、リクエストの送信に使用するブラウザのタイプに応じてアクセスを許可するときに使用します。たとえば、Netscapeブラウザからのリクエストのみにアクセスを許可する場合は、例7-6に示されている構文を使用します。

例7-6    環境変数を使用したアクセス制御

BrowserMatch ^Mozilla netscape_browser
<Directory /mozilla-area/>
  order deny,allow
  deny from all
  allow from env=netscape_browser
</Directory>

SetEnvIfは、HTTPリクエストに含まれているヘッダー情報に応じてアクセスを許可するときに使用します。たとえば、HTTPバージョン1.0以前を使用するブラウザからのアクセスを拒否する場合は、例7-7に示されている構文を使用します。

例7-7    SetEnvによるアクセス制御

SetEnvIf Request_Protocol ^HTTP/1.1 http_11_ok
<Directory /http1.1only/>
  order deny,allow
  deny from all
  allow from env=http_11_ok
</Directory>

7.4.2 ユーザーの認証と認可

Basic認証では、HTTPリクエストにサービスを提供する前に、ユーザー名とパスワードを求めるプロンプトを表示します。ブラウザが保護領域のページをリクエストすると、Oracle HTTP ServerはWWW-Authenticate:ヘッダーと構成ディレクティブAuthNameにより構成されているレルムの名前を含む、不認可のメッセージ（ステータス・コード401）をレスポンスとして返します。ブラウザはこのレスポンスを受信すると、ユーザー名とパスワードを求めるプロンプトを表示します。ユーザーがユーザー名とパスワードを入力した後、ブラウザはこの情報を認可ヘッダーに入れてサーバーに返します。認可ヘッダー・メッセージ内では、ユーザー名とパスワードはBASE64エンコード文字列としてエンコードされます。

ユーザー認可では、特定のサーバー・リソース（ファイルやディレクトリなど）に関連付けられているアクセス制御リストに照らして、認証済ユーザーがチェックされます。ユーザー認可を構成するには、通常は仮想ホスト・コンテナ内にあるhttpd.confファイルにrequireディレクティブを指定します。ユーザー認可は、一般に、ユーザー認証と組み合せて使用されます。サーバーはユーザーの名前とパスワードを認証した後、リクエストされたサーバー・リソースに関連付けられているアクセス制御リストとそのユーザーを比較します。Oracle HTTP Serverにより、リスト上にユーザーまたはユーザー・グループが見つかると、そのユーザーがリソースを使用できるようになります。

7.4.2.1 ユーザー認証のためのmod_authの使用

ユーザー認証はユーザー名とパスワードに基づきますが、この2つは既知のユーザーおよびパスワードのリストに照らしてチェックされます。このユーザー名とパスワードのペアは、テキスト・ファイル、データベースまたはディレクトリ・サービスなど様々な形で格納できます。次に、構成ディレクティブがhttpd.confファイルで使用され、サーバー上にこのタイプのユーザー認証を構成します。mod_authでは、Basic認証の設定にAuthUserFileディレクティブを使用します。これは、ファイルのみをサポートします。

どの認証方法の場合にも、表7-1に示される構成ディレクティブを組み合せて使用する必要があります。

表7-1    ディレクティブの説明 
ディレクティブ名  説明 

AuthName 

ユーザー名とパスワードが有効なレルムの名前を定義します。名前にスペースが含まれている場合は、二重引用符を使用します。 

AuthType 

認証タイプを指定します。ほとんどの認証モジュールではBasic認証を使用します。この認証タイプでは、ユーザー名とパスワードをクリアテキストで送信します。これはお薦めしません。 

AuthUserFile 

ユーザー名とパスワードを含むファイルのパスを指定します。 

AuthGroupFile 

グループの名前とメンバーを含むファイルのパスを指定します。 

7.4.2.2 ユーザー認証のためのmod_ossoの使用

mod_ossoにより、Oracle HTTP Serverでシングル・サインオンがオンになります。mod_ossoでは、受信リクエストを検査してリクエストされたリソースが保護されているかどうかを判断し、保護されている場合はユーザー用のOracle HTTP Server Cookieを取得します。

Oracle HTTP Serverは、mod_ossoを使用して、シングル・サインオン（SSO）パートナ・アプリケーションになります。このアプリケーションは、ユーザーの認証とユーザー識別情報の取得にOracle Single Sign-Onを使用し、ユーザー識別情報をApacheヘッダー変数としてWebアプリケーションに提供することができます。

Webアプリケーションは、mod_ossoを使用してSSO認証が必要なURLを登録できます。Oracle HTTP ServerがURLリクエストを受信すると、mod_ossoはSSO認証の必要なリクエストを検出し、このリクエストをSSOサーバーにリダイレクトします。SSOサーバーがユーザーを認証した後、サーバーはユーザーの認証識別情報をセキュリティで保護されたトークンまたはCookieに入れてmod_ossoに返します。mod_ossoはCookieからユーザーの識別情報を取り出し、Oracle HTTP Serverインスタンス内で実行中のアプリケーションにユーザーの識別情報を伝播します。mod_ossoは、CGIで実行中のアプリケーションとOC4Jで実行中のアプリケーションにユーザーの識別情報を伝播することができ、また、静的ファイルにアクセスするユーザーを認証することもできます。

関連資料

 

7.4.2.3 ユーザー認証のためのmod_osslの使用

mod_osslはOracle HTTP Serverへのプラグインで、サーバーがSSLを使用できるようにします。Oracle HTTP Server製品では、mod_sslがmod_osslに置き換わっています。mod_sslはサポートされていません。

関連項目

mod_osslのディレクティブを使用したSSLの有効化および構成の詳細は、第8章「Oracle HTTP ServerでのSSLの有効化」を参照してください。 

7.5 ポート・トンネリングの概要

ポート・トンネリングを使用すると、Oracle HTTP ServerとOC4J間のすべての通信を1つまたは少数のポート上で行えます。以前は、Oracle HTTP Serverと複数のOC4Jインスタンス間の通信を処理するには、ファイアウォール構成に多数のポートのポート情報を含める必要がありました。

関連資料

ポート・トンネリングの詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。 

7.5.1 ポート・トンネリングの構成

ポート・トンネリングを構成するには、次の3つのタスクを実行します。

7.5.1.1 タスク1: opmn.xmlの構成

中間層（スタンドアロンのOracle HTTP Server 2.0ではない）に対して次の手順を実行し、1つ以上のiasptデーモンを起動します。

  1. デフォルトでは、無効化されているiasptのopmn.xmlエントリがあります。opmn.xmlを編集し、status="disable"をstatus="enable"に変更して、iasptを有効化します。

  2. オプションとして、ポート範囲を変更してiasptデーモンで使用されるTCP/IPポートを変え、numprocsを変更してiasptデーモン・プロセスの数を変えることができます。

    次に、iasptデーモンの完全な構成例を示します。このコンポーネントとともに使用できるすべての構成要素または属性が含まれています。 

    <module path="/ORACLE_HOME/opmn/lib/libopmniaspt"> 
  <module-id id="IASPT" /> 
</module> 
<ias-component id="IASPT" status="enabled" id-matching="false">
  <process-type id="IASPT" module-id="IASPT"> 
    <port id="ajp" range="6701-6703"/>
    <process-set id="IASPT" restart-on-death="true" numprocs="3"/>
  </process-type> 
</ias-component>
  3. 次のコマンドを実行して、opmnデーモンに構成ファイルのリロードを指示します。

    opmnctl reload

7.5.1.2 タスク2: iaspt.confの構成

中間層（スタンドアロンのOracle HTTP Server 2.0ではない）に対して次の手順を実行し、iasptデーモンが使用するSSLウォレットを指定するためのiaspt.confの構成を行います。

  1. mod_oc4jとiaspt間の通信は、必ず暗号化されます。そのため、SSLウォレット・ファイルはiasptデーモン用に構成する必要があります。デフォルトでは、このウォレットはOracle HTTP Serverウォレットと同じです。このデフォルトは、iaspt.confの次の値を編集すると変更できます。

    wallet-file=<path to wallet file>
wallet-password=<password>

    関連項目

     

  2. 次のコマンドを使用して、iasptデーモンを起動します。

    opmnctl startall

7.5.1.3 タスク3: mod_oc4j.confの構成

スタンドアロンのOracle HTTP Server 2.0（中間層ではない）に対して次の手順を実行し、iasptを使用してリクエストをルーティングするためのmod_oc4j.confの構成を行います。

  1. 次の行をmod_oc4j.confに追加して、ポート・トンネリングを有効にします。

    Oc4jiASPTActive on

    関連項目

    「Oc4jiASPTActive」 

  2. 次の2行をmod_oc4j.confに追加して、SSLウォレットおよびウォレット・パスワードをmod_oc4j.confに指定します。

    Oc4jiASPTWalletFile <path to wallet file>
Oc4jiASPTWalletPassword <password of wallet>

    このウォレットは、Oracle HTTP Serverまたはiaspt（あるいはその両方）で使用されるものと同じでもかまいません。

    関連資料

     

  3. iasptデーモンのホストおよびポート・アドレスを指定します。たとえば、次の行をmod_oc4j.confに追加します。

    Oc4jiASPTProcess myhost.us.oracle.com:6701

    保持するiasptデーモンと同じ数のOc4jiASPTProcessの行を追加できます。ホストおよびポート・アドレスは、構成されたiasptデーモンのものと一致する必要があります。たとえば、「タスク1: opmn.xmlの構成」の手順2の例で構成した3つのiasptデーモンにリクエストをルーティングするには、次の3行を追加します。

    Oc4jiASPTProcess myhost.us.oracle.com:6701
Oc4jiASPTProcess myhost.us.oracle.com:6702
Oc4jiASPTProcess myhost.us.oracle.com:6703

    関連項目

    「Oc4jiASPTProcess」 

  4. 次のコマンドを使用して、Oracle HTTP Serverを再起動し、変更を有効にします。

    • UNIXの場合: ORACLE_HOME/opmn/bin> opmnctl [verbose] restartproc ias-component=HTTP_Server

    • Windowsの場合: ORACLE_HOME¥opmn¥bin> opmnctl [verbose] restartproc ias-component=HTTP_Server

7.5.2 ポート・トンネリング用のSSLの構成

この項では、iasptとOC4J間でのSSLの構成について説明します。

デフォルトでは、iasptデーモンとOC4Jプロセスは、暗号化されていないデータを使用して通信を行います。これらのプロセス間のSSL通信を構成するには、次の手順を実行します。

  1. iaspt.confで、destination-sslの値をfalseからtrueに変更します。

  2. SSLを使用するようにOC4Jプロセスを構成する方法については、『Oracle Containers for J2EEセキュリティ・ガイド』を参照してください。

7.5.3 ポート・トンネリングの構成のリファレンス

この項では、次の構成ファイルとそのパラメータについて説明します。

7.5.3.1 opmn.xml

Oracle Application Server内でOPMNにより管理されるプロセスを記述します。

関連項目

「opmn.xml」 

ポート・トンネリングの一環として、起動されるiasptデーモン・プロセスを記述するエントリがOPMNに存在する必要があります。このエントリには次の記述を含めます。

デフォルトのOracle Application Serverでは、iasptコンポーネントはopmn.xmlに含まれていますが、無効化されています。

7.5.3.2 mod_oc4j.conf

Oracle HTTP Serverによりmod_oc4jを構成します。

関連項目

「mod_oc4j.conf」 

ポート・トンネリング用に、次を指定したディレクティブを追加する必要があります。

デフォルトでは、mod_oc4jはOC4Jと直接通信します。ポート・トンネリング・プロセスの場合、mod_oc4jはiasptデーモンを介してOC4Jに通信する必要があります。

次のディレクティブを使用して、mod_oc4jをiasptデーモンに接続します。

Oc4jiASPTActive

mod_oc4jがリクエストをルーティングするときにポート・トンネリングを考慮する必要があるかどうかを示します。Oc4jEnableSSLが「On」に構成されている場合、このディレクティブは「On」に構成しないでください。ポート・トンネリング・プロセスを有効化するには、このディレクティブを「On」に設定します。

カテゴリ  値 

パラメータ名 

Oc4jiASPTActive 

パラメータ・タイプ 

文字列 

有効値 

OnまたはOff 

デフォルト値 

Off 

Oc4jiASPTProcess

ポート・トンネリング・プロセスのリスニング・ホストおよびポートを記述します。mod_oc4j.confファイル内で、複数のポート・トンネリング・プロセス用にこのディレクティブの複数のインスタンスを指定できます。

このディレクティブの構文は、host:portです。host値は、iasptデーモンが実行されているマシンのホスト名と一致する必要があります。port値は、そのiasptのopmn.xmlに構成されているポートと一致する必要があります。hostには、標準のホスト名とIPアドレスの両方を使用できます。

カテゴリ  値 

パラメータ名 

Oc4jiASPTProcess 

パラメータ・タイプ 

文字列 

有効値 

使用可能なiasptデーモンのhost:port値 

デフォルト値 

該当なし 

構文 

host:port

例: myhost.us.oracle.com:6667 

mod_oc4jはiasptデーモンと通信する際にSSLを使用する必要があります。次に、SSLの有効化に使用されるディレクティブを示します。

Oc4jiASPTWalletFile

iasptデーモンとのSSL通信に使用されるSSL証明書を含む、Oracleウォレット・ファイルの位置を指定します。

カテゴリ  値 

パラメータ名 

Oc4jiASPTWalletFile 

パラメータ・タイプ 

文字列 

有効値 

iasptデーモンとのSSL接続確立時に使用されるSSL証明書を含むウォレット・ファイルへのパス 

デフォルト値 

該当なし 

構文 

有効なファイル名

例: /foo/bar/myfilename 

Oc4jiASPTWalletPassword

ウォレット・ファイルのオープン時に認証に使用される不明瞭化されたパスワードの値を指定します。この値は、Oracle Wallet Managerに含まれているユーティリティを使用して取得されます。

カテゴリ  値 

パラメータ名 

Oc4jiASPTWalletPassword 

パラメータ・タイプ 

文字列 

有効値 

Oc4jiASPTWalletFileにより指定されたウォレット・ファイルのオープン時に認証に使用されるパスワード 

デフォルト値 

該当なし 

関連資料

Oracle Wallet Managerの詳細は、『Oracle Application Server管理者ガイド』を参照してください。 

7.5.3.3 iaspt.conf

ポート・トンネリングを構成します。

関連項目

「iaspt.conf」 

このファイルは、次の情報を示します。

iaspt.confファイルには、一連の名前/値ペアが含まれます。次に、受け入れられるパラメータの名前を示します。

wallet-file

ピアとのSSL通信に使用するSSL証明書を含む、Oracleウォレット・ファイルの位置を指定します。

カテゴリ  値 

パラメータ名 

wallet-file 

パラメータ・タイプ 

文字列 

有効値 

他のプロセスとのSSL接続確立時に使用されるSSL証明書を含むウォレット・ファイルへのパス 

デフォルト値 

該当なし 

構文 

有効なファイル名

例: /foo/bar/myfilename 

wallet-password

ウォレット・ファイルのオープン時に認証に使用されるパスワードの値を指定します。この値は、Oracle Wallet Managerに含まれているユーティリティを使用して取得されます。

カテゴリ  値 

パラメータ名 

wallet-password 

パラメータ・タイプ 

文字列 

有効値 

wallet-fileにより指定されたウォレット・ファイルのオープン時に認証に使用されるパスワード 

デフォルト値 

該当なし 

関連資料

Oracle Wallet Managerの詳細は、『Oracle Application Server管理者ガイド』を参照してください。 

log-file

iasptデーモンのログ・メッセージが書き込まれるログ・ファイルのパスを指定します。

カテゴリ  値 

パラメータ名 

log-file 

パラメータ・タイプ 

文字列 

有効値 

iasptデーモンのログ・メッセージが書き込まれるログ・ファイルのパス 

デフォルト値 

該当なし 

構文 

有効なファイル名

例: /foo/bar/myfilename 

log-level

ログ・レベルを指定します。9が最高で、0はロギングしないことを意味します。

カテゴリ  値 

パラメータ名 

log-level 

パラメータ・タイプ 

整数 

有効値 

整数（0〜9） 

デフォルト値 

3 

iaspt-port

iasptデーモンが接続を受け入れるポートの値を指定します。このパラメータはオプションです。

カテゴリ  値 

パラメータ名 

iaspt-port 

パラメータ・タイプ 

整数 

有効値 

有効なTCP/IPポート値 

構文 

整数

例: 9898 

デフォルト値 

該当なし 

7.6 Oracle Identity Managementインフラストラクチャの利用

この項では、Oracle HTTP ServerによるOracle Identity Managementインフラストラクチャの使用方法を説明します。

7.6.1 概要

Oracle Identity Managementは、分散セキュリティのためにOracle Application Serverが依存する統合インフラストラクチャです。これは、Oracle Internet Directory、Oracle Directory Integration and Provisioning、Delegated Administration Services、Oracle Single Sign-OnおよびOracle Application Server Certificate Authorityで構成されています。

関連資料

『Oracle Identity Managementインフラストラクチャ管理者ガイド』 

7.6.2 Oracle Single Sign-Onとmod_ossoの使用

Oracle Application Serverでは、Oracle Single Sign-Onにより、Webベース・アプリケーションに対するシングル・サインオン（SSO）をサポートしています。ユーザーはOracle Single Sign-Onを使用してOracle Application Serverにログインし、認可されているアプリケーションにアクセスできます。アプリケーションごとにユーザー名とパスワードを再入力する必要はありません。これは、ユーザー情報を格納するOracle Internet Directoryと完全に統合されています。Oracle Internet Directoryを使用して、LDAPベースのユーザーおよびパスワードの管理をサポートします。

Oracle HTTP Serverモジュールのmod_ossoを使用すると、Oracle Application Server全体でOracle Single Sign-Onを透過的に使用できます。Oracle HTTP Serverは、mod_ossoを使用して、SSOパートナ・アプリケーションになります。このアプリケーションは、ユーザーの認証とユーザー識別情報の取得にSSOを使用し、ユーザー識別情報をApacheヘッダー変数としてWebアプリケーションに提供することができます。

関連項目

「ユーザー認証のためのmod_ossoの使用」 

戻る 次へ
Oracle
Copyright © 2007 Oracle Corporation.
All Rights Reserved.
目次
目次		 索引
索引