10g（10.1.3.1.0）
B31847-01
 目次 |
 索引 |
| Oracle HTTP Server 管理者ガイド
10g（10.1.3.1.0） B31847-01 |
|
この章では、Oracle HTTP Serverのセキュリティ機能、およびセキュアなWebサイトを設定するための構成情報について説明します。
内容は、次のとおりです。
セキュリティ機能は、認証、認可および機密保護という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リスナーに共通のモジュール（プラグイン）アーキテクチャを使用して実装されています。
図9-1は、サーバーによるURLリクエストの処理方法を示したものです。このプロセスの各手順は、サーバー・モジュールによりサーバーの構成に応じて処理されます。たとえばBasic認証が使用される場合、図9-1の認証および認可という手順は、mod_authモジュールの処理を示します。
Oracle HTTP Serverではユーザーの認可および認証を行い、それによってユーザーは、サーバー上のリソースへのアクセスやリソースの変更を許可されます。Oracle HTTP Serverを使用してサーバーにアクセスするユーザーの3つのクラスとその権限は、次のとおりです。
mod_authおよびmod_osslにより認証されたユーザーが含まれます。このようなユーザーは、http.confファイルに定義されているURLにアクセスできます。mod_ossoおよびSingle Sign-On Serverにより認証されたユーザー。このユーザーは、Single Sign-Onにより許可されているリソースにアクセスできます。Oracle HTTP Serverは、次のようなリソースを保護するように構成されています。
.gif）ファイルおよびOracle HTTP Serverが直接提供するその他の静的ファイルなど。
Oracle HTTP Serverは、ユーザーの認証と認可を2段階で提供します。
リクエスト処理サイクルの初期にアクセス制御が適用されます。これにより、ホスト名、IPアドレスまたはその他の特性（ブラウザ・タイプなど）に基づいて、後続の処理を禁止できます。このタイプのアクセス制御を設定するには、deny、allowおよびorderディレクティブを使用します。この制限はOracle HTTP Server構成ディレクティブを使用して構成します。例9-1に示すように、<Files>、<Directory>および<Location>コンテナ・ディレクティブを使用し、特定のファイル、ディレクトリまたはURLフォーマットに基づいて制限できます。
<Directory /internalonly/> order deny, allow deny from all allow from 192.168.1.* us.oracle.com </Directory>
例9-1で、orderディレクティブは、Oracle HTTP Serverがdenyおよびallowディレクティブの条件を読み取る順序を決定します。denyディレクティブでは、すべてのリクエストがアクセスを拒否されます。次に、allowディレクティブを使用して、192.168.1.*範囲内の任意のIPアドレスから送信されるリクエストまたはドメイン名us.oracle.comを持つリクエストに対して、ディレクトリ/internalonly/内のファイルへのアクセスが許可されます。ホストベースの認証では、アクセス・ポリシーを明示的にするために、allowとdenyの両方を指定するのが一般的な方法です。
ファイル・システム・レベルでオブジェクトを比較する場合は、<Directory>または<Files>を使用する必要があります。URLレベルでオブジェクトを比較する場合は、<Location>を使用する必要があります。
仮想ホストにアクセス制御を設定するには、サーバー構成ファイルhttpd.conf内の仮想ホスト・コンテナの中にAccessConfigディレクティブを指定します。AccessConfigディレクティブを仮想ホスト・コンテナ内で使用すると、ファイル内に含まれるアクセス制御ポリシーが指定されます。例9-2は、httpd.confファイルからの抜粋です。AccessConfigをこの方法で使用するための構文が示されています。
... <VirtualHost ip_address_of_host.some_domain.com> ... virtual host directives ... AccessConfig conf/access.conf </VirtualHost>
ホストベースのアクセス制御方法を使用すると、HTTPリクエストの発信元に基づいて制限領域へのアクセスを制御できます。Oracle HTTP Serverではmod_accessとmod_setenvifを使用して、ホストベースのアクセス制御を実行します。mod_accessは、クライアントのホスト名、IPアドレスまたはクライアント・リクエストのその他の特性に基づいてアクセス制御を提供し、mod_setenvifは、リクエストの属性に基づいて環境変数を設定する機能を提供します。これらのモジュールを使用する構成ディレクティブをhttpd.confファイルに入力すると、サーバーでは、ホストのアドレス、名前またはHTTPリクエスト・ヘッダーの内容に基づいて、リクエストを実行あるいは拒否します。
ホストベース・アクセス制御を使用すると、静的なHTMLページ、アプリケーションまたはコンポーネントを保護できます。
Oracle HTTP Serverは、次の4種類のホストベース・アクセス制御方法をサポートします。
これらの方法ではすべて、保護領域へのアクセス権が付与または拒否されるマシンを指定できます。ホストベースのアクセス制御方法のどれを選択するか（複数も可）は、制限されているコンテンツやアプリケーションをどの方法が最も効率的に保護するか、またはどの方法が最も保守しやすいかによって決まります。
IPアドレスを使用したアクセス制御は、ホストベースのアクセス制御でよく使用される方法です。この方法では、DNS参照を必要としません。DNS参照には時間とシステム・リソースがかかり、サーバーがDNSスプーフィング攻撃を受けやすくなります。
<Directory /secure_only/> order deny,allow deny from all allow from 207.175.42.* </Directory>
例9-3では、207.175.42.*範囲を除いたすべてのIPアドレスからのリクエストは、/secure_only/ディレクトリへのアクセスを拒否されます。
ドメイン名ベースのアクセス制御をIPアドレスベースのアクセス制御とともに使用すると、IPアドレスが警告なしで変更される問題が解決します。この2つの方法を組み合せると、IPアドレスが変更される場合でも、排除するドメイン名はアクセスを拒否されるため、サイトの制限領域が保護されます。
ドメイン名ベースとIPアドレスベースのアクセス制御を組み合せるには、例9-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>
例9-4では、/co_backgr/ディレクトリに対するリクエストは、ドメイン名malicious.cracker.comまたはIPアドレス範囲141.217.24.*からのリクエストを除いて、すべて受信されます。これは、ドメイン名またはIPアドレスのスプーフィングに対する絶対的な予防措置ではありませんが、malicious.cracker.comがIPアドレスを変更している場合でも、ここからの攻撃に対してサイトを保護します。
ネットワークのサブセット（IPアドレスにより指定）に基づいてアクセスを制御できます。この構文を例9-5に示します。
<Directory /payroll/> order deny,allow deny from all allow from 10.1.0.0/255.255.0.0 </Directory>
例9-5では、ネットワークとネットマスクのペアからのアクセスが許可されます。ネットマスクは、IPアドレスをネットワーク、サブネットおよびホスト識別子に分割する方法を示したものです。ネットマスクを使用すると、IPアドレスのホストID部分のみを参照できます。
例9-5のネットマスク255.255.0.0は、クラスBアドレスのデフォルト・ネットマスク設定です。バイナリの1（10進の255）がネットワークIDをマスクし、バイナリの0（ゼロ）（10進のゼロ）が、指定されたIPアドレスのホストIDを保持します。
アクセス制御には、IPアドレスやドメイン名のかわりに任意の環境変数を使用できます。このタイプのアクセス制御には、BrowserMatchおよびSetEnvIfディレクティブを使用します。
BrowserMatchは、リクエストの送信に使用するブラウザのタイプに応じてアクセスを許可するときに使用します。たとえば、Netscapeブラウザからのリクエストのみにアクセスを許可する場合は、例9-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以前を使用するブラウザからのアクセスを拒否する場合は、例9-7に示されている構文を使用します。
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>
Basic認証では、HTTPリクエストにサービスを提供する前に、ユーザー名とパスワードを要求します。ブラウザが保護領域のページをリクエストすると、Oracle HTTP ServerはWWW-Authenticate:ヘッダーと構成ディレクティブAuthNameにより構成されているレルムの名前を含む、不認可のメッセージ（ステータス・コード401）をレスポンスとして返します。ブラウザはこのレスポンスを受信すると、ユーザー名とパスワードの入力を要求します。ユーザーがユーザー名とパスワードを入力した後、ブラウザはこの情報を認可ヘッダーに入れてサーバーに返します。認可ヘッダー・メッセージ内では、ユーザー名とパスワードはBASE64エンコード文字列としてエンコードされます。
ユーザー認可では、特定のサーバー・リソース（ファイルやディレクトリなど）に関連付けられているアクセス制御リストに照らして、認証済ユーザーがチェックされます。ユーザー認可を構成するには、通常は仮想ホスト・コンテナ内にあるhttpd.confファイルにrequireディレクティブを指定します。ユーザー認可は、一般に、ユーザー認証と組み合せて使用されます。サーバーはユーザーの名前とパスワードを認証した後、リクエストされたサーバー・リソースに関連付けられているアクセス制御リストとそのユーザーを比較します。Oracle HTTP Serverにより、リスト上にユーザーまたはユーザー・グループが見つかると、そのユーザーがリソースを使用できるようになります。
ユーザー認証は、既知のユーザーおよびパスワードのリストに照らしてチェックされるユーザー名とパスワードに基づいて行われます。このユーザー名とパスワードのペアは、テキスト・ファイル、データベースまたはディレクトリ・サービスなど様々な形で格納できます。次に、構成ディレクティブがhttpd.confファイルで使用され、サーバー上にこのタイプのユーザー認証を構成します。mod_authでは、Basic認証の設定にAuthUserFileディレクティブを使用します。これは、ファイルのみをサポートします。
どの認証方法の場合にも、表9-1に示した構成ディレクティブを組み合せて使用する必要があります。
mod_ossoにより、Oracle HTTP Serverでシングル・サインオンが有効になります。mod_ossoでは、受信リクエストを検査してリクエストされたリソースが保護されているかどうかを判断し、保護されている場合はそのユーザーのOracle HTTP Server Cookieを取得します。
Oracle HTTP Serverは、mod_ossoを使用して、シングル・サインオン（SSO）パートナ・アプリケーションになります。このアプリケーションは、ユーザーの認証とユーザー識別情報の取得にOracle Application Server 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で実行中のアプリケーションにユーザーの識別情報を伝播することができ、また、静的ファイルにアクセスするユーザーを認証することもできます。
mod_osslは、サーバーでSSLが使用できるようにするOracle HTTP Serverに対するプラグインです。Oracle HTTP Server製品では、mod_sslがmod_osslに置き換わっています。mod_sslはサポートされなくなりました。
ポート・トンネリングを使用すると、Oracle HTTP ServerとOC4J間のすべての通信を1つまたは少数のポート上で行えます。以前は、Oracle HTTP Serverと複数のOC4Jインスタンス間の通信を処理するには、ファイアウォール構成に多数のポートのポート情報を含める必要がありました。ポート・トンネリングを使用すると、iasptと呼ばれるデーモンが適切なOC4Jインスタンスにリクエストをルーティングします。関連するOC4Jインスタンスの数にかかわらず、ファイアウォール経由で開かれている必要のあるポートは1つのみ、または少数です。その結果、Oracle HTTP ServerとOC4J間の通信のセキュリティはより高度になります。
これを可能にするために、通常はクライアントとOracle HTTP Server間、およびOracle HTTP ServerとOC4J間にそれぞれファイアウォールが存在する非武装地帯環境が設定されます。この構成では、Oracle HTTP Serverは2つのファイアウォールにはさまれたDMZに位置します。OC4Jと他のビジネス・ロジック・コンポーネントは、イントラネット内でこの2つのファイアウォールの後方に位置します。最高度のセキュリティを保証するために、マシン間で送信される通信はすべてSSLを使用して暗号化されます。ポート・トンネリングは、この最高レベルのセキュリティを柔軟かつ管理しやすい方法でサポートするフレームワークであり、これによりパフォーマンスが向上します。
提示されるポート範囲は7501〜7599で、デフォルトは7501ですが、必要なポートを選択できます。
図9-2は、ポート・トンネリングを使用したOracle Application Server構成を示しています。スタンドアロン・コンポーネントのiasptデーモンが、Oracle HTTP ServerとOC4Jを含むJava仮想マシン（JVM）間の接続の通信コンセントレータとして機能します。Oracle HTTP ServerはOC4Jには直接接続しません。かわりにiasptデーモンに接続し、このデーモンが通信をOC4Jにディスパッチします。このような接続の集中化により、OC4Jインスタンスごとにポートが1つ開かれるのではなく、内部ファイアウォール上のポート・トンネリングごとにポートが1つ開かれます。
Oracle HTTP Serverとiasptデーモン間の通信は、SSLを使用して暗号化されます。SSLクライアント証明書を使用してこれらの接続が確立されたときに、認証が有効になります。これらの接続は永続的で、接続リソースに応じて適切な期間維持されます。リクエストが、どのサーブレット・エンジンにルーティングされるかを示すルーティング情報を含むように変更された、AJP 1.3プロトコルが使用されます。
ポート・トンネリングは、Oracle HTTP ServerとOC4J間の接続をサポートします。OC4Jをサポートするために、Oracle HTTP Serverモジュールのmod_oc4jがSSL暗号化通信を使用し、ポート・トンネリング・プロセス経由でリクエストをルーティングするように変更されます。ポート・トンネリングは、静的構成をサポートします。
iasptデーモンは、マシン1台につき少なくとも1つ必要です。iasptデーモンは、可用性を高くするために複数実行できます。Oracle HTTP Serverでは、複数のiasptデーモン間においてリクエストをパーティション化するラウンド・ロビンと、アプリケーションのパーティション化をサポートします。また、Oracle HTTP Serverでは、指定されたiasptデーモンに送信できないリクエストの自動フェイルオーバーもサポートします。
ポート・トンネリングを構成するには、次のタスクを実行します。
1つ以上のiasptデーモンを起動するには、次の手順を実行します。
iasptのopmn.xmlエントリがあります。opmn.xmlを編集し、status="disable"をstatus="enable"に変更して、iasptを有効にします。
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>
opmnctl reload
iaspt.confを構成して、使用するiasptデーモンにSSL Walletを指定するには、次の手順を実行します。
mod_oc4jとiaspt間の通信は、必ず暗号化されます。そのため、SSL Walletファイルはiasptデーモン用に構成する必要があります。デフォルトでは、このWalletはOracle HTTP Server Walletと同じです。このデフォルトは、iaspt.confの次の値を編集すると変更できます。
wallet-file=<path to wallet file> wallet-password=<password>
opmnctl startall
mod_oc4j.confを構成し、iasptを使用してリクエストをルーティングするには、次の手順を実行します。
mod_oc4j.confに追加して、ポート・トンネリングを有効にします。
Oc4jiASPTActive on
mod_oc4j.confに追加して、SSL WalletおよびWalletパスワードをmod_oc4j.confに指定します。
Oc4jiASPTWalletFile <path to wallet file> Oc4jiASPTWalletPassword <password of wallet>
このWalletは、Oracle HTTP Serverまたはiaspt（あるいはその両方）で使用されるものと同じでもかまいません。
|
関連項目
|
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
この項では、iasptとOC4J間でのSSLの構成について説明します。
デフォルトでは、iasptデーモン・プロセスとOC4Jプロセスは、暗号化されていないデータを使用して通信を行います。これらのプロセス間のSSL通信を構成するには、次の手順を実行します。
iaspt.confで、値destination-sslをfalseからtrueに変更します。
この項では、次の構成ファイルとそれらのパラメータについて説明します。
Oracle Application Server内でOPMNにより管理されるプロセスを記述します。
ポート・トンネリングの一環として、起動されるiasptデーモン・プロセスを記述するエントリがOPMNに存在する必要があります。このエントリには次の記述を含めます。
デフォルトのOracle Application Serverでは、iasptコンポーネントはopmn.xmlに含まれていますが、無効になっています。
Oracle HTTP Serverによりmod_oc4jを構成します。
ポート・トンネリング用に、次の指定を行うディレクティブを追加する必要があります。
デフォルトでは、mod_oc4jはOC4Jと直接通信します。ポート・トンネリング・プロセスの場合、mod_oc4jはiasptデーモンを介してOC4Jに通信する必要があります。
次に、mod_oc4jをiasptデーモンに接続するために使用されるディレクティブを示します。
mod_oc4jがリクエストをルーティングするときにポート・トンネリングを考慮する必要があるかどうかを示します。Oc4jEnableSSLがOnに構成されている場合、このディレクティブはOnに構成しないでください。ポート・トンネリング・プロセスを有効にするには、このディレクティブをOnに設定します。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
|
|
デフォルト値 |
|
ポート・トンネリング・プロセスのリスニング・ホストおよびポートを記述します。mod_oc4j.confファイル内で、複数のポート・トンネリング・プロセス用にこのディレクティブの複数のインスタンスを指定できます。
このディレクティブの構文は、host:portです。host値は、iasptデーモンが実行されているマシンのホスト名と一致する必要があります。port値は、そのiasptのopmn.xmlに構成されているポートと一致する必要があります。hostには、標準のホスト名とIPアドレスの両方を使用できます。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
使用可能な |
|
デフォルト値 |
該当なし |
|
構文 |
例: |
mod_oc4jはiasptデーモンと通信するときにSSLを使用する必要があります。次に、SSLの有効化に使用されるディレクティブを示します。
iasptデーモンとのSSL通信に使用されるSSL証明書を含む、Oracle Walletファイルの場所を指定します。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
iasptデーモンとのSSL接続確立時に使用されるSSL証明書を含むWalletファイルへのパス。 |
|
デフォルト値 |
該当なし |
|
構文 |
例: |
Walletファイルを開くときに認証に使用される不明瞭化されたパスワードの値を指定します。この値は、Oracle Wallet Managerに含まれているユーティリティを使用して取得されます。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
Oc4jiASPTWalletFileにより指定されたWalletファイルを開く際に認証に使用されるパスワード。 |
|
デフォルト値 |
該当なし |
ポート・トンネリングを構成します。
このファイルでは、次の情報を指定します。
iasptデーモンがリスニングするポート（オプション）。このポートは、iaspt.conf内に指定するか、ポートの範囲を指定してopmn.xmlから渡すことができます。これにより、複数のポート・トンネリング・プロセスで同じiaspt.confファイルを使用できます。
iaspt.confファイルには、一連の名前/値ペアが含まれます。受け入れられるパラメータ名は、次のとおりです。
ピアとのSSL通信に使用するSSL証明書を含む、Oracle Walletファイルの場所を指定します。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
他のプロセスとのSSL接続確立時に使用されるSSL証明書を含むWalletファイルへのパス。 |
|
デフォルト値 |
該当なし |
|
構文 |
例: |
Walletファイルのオープン時に認証に使用されるパスワードの値を指定します。この値は、Oracle Wallet Managerに含まれているユーティリティを使用して取得されます。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
wallet-fileにより指定されたWalletファイルを開く際の認証に使用されるパスワード |
|
デフォルト値 |
該当なし |
iasptデーモンのログ・メッセージが書き込まれるログ・ファイルのパスを指定します。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
文字列 |
|
有効値 |
|
|
デフォルト値 |
該当なし |
|
構文 |
例: |
ログギング・レベルを指定します。9が最高で、0はロギングを行わないことを意味します。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
整数 |
|
有効値 |
整数（0〜9） |
|
デフォルト値 |
3 |
iasptデーモンが接続を受け入れるポートの値を指定します。このパラメータはオプションです。
| カテゴリ | 値 |
|---|---|
|
パラメータ名 |
|
|
パラメータ・タイプ |
整数 |
|
有効値 |
有効なTCP/IPポート値 |
|
構文 |
例: 9898 |
|
デフォルト値 |
該当なし |
この項では、Oracle HTTP ServerによるOracle Identity Managementの使用方法を説明します。
Oracle Identity Managementは、分散セキュリティのためにOracle Application Serverが依存する統合インフラストラクチャです。これは、Oracle Internet Directory、Oracle Directory Integration and Provisioning、Oracle Delegated Administration Services、Oracle Application Server Single Sign-OnおよびOracle Application Server Certificate Authorityで構成されています。
Oracle Application Serverは、Oracle Application Server Single Sign-Onを使用して、Webベース・アプリケーションに対するシングル・サインオン（SSO）をサポートします。Oracle Application Server Single Sign-Onを使用して、Oracle Application Serverにログインし、認可されているアプリケーションにアクセスできます。アプリケーションごとにユーザー名とパスワードを再入力する必要はありません。これは、ユーザー情報を格納するOracle Internet Directoryと完全に統合されています。Oracle Internet Directoryを使用して、LDAPベースのユーザーおよびパスワードの管理をサポートします。
Oracle HTTP Serverモジュールのmod_ossoを使用すると、Oracle Application Server全体でOracle Application Server Single Sign-Onを透過的に使用できます。Oracle HTTP Serverは、mod_ossoを使用して、SSOパートナ・アプリケーションになります。このアプリケーションは、ユーザーの認証とユーザー識別情報の取得にSSOを使用し、ユーザー識別情報をApacheヘッダー変数としてWebアプリケーションに提供することができます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|