Sun Java System Portal Server Secure Remote Access 7.2 管理ガイド

第 2 章ゲートウェイの操作

この章では、ゲートウェイに関連する概念について説明します。ゲートウェイの管理については、第 16 章「ゲートウェイの管理」を参照してください。ゲートウェイの設定については、第 8 章「Secure Remote Access ゲートウェイの設定」を参照してください。

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

ゲートウェイの概要

ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。ゲートウェイはリモートユーザーとの単一のインタフェースを通じて、内部 Web サーバーとアプリケーションサーバーのコンテンツを安全に提供します。

ゲートウェイインスタンスごとに、次のタスクを完了してください。

そのほかに、次のゲートウェイ関連トピックがあります。

ゲートウェイプロファイルの作成

ゲートウェイプロファイルには、ゲートウェイが待機するポート、SSL オプション、およびプロキシオプションなどのゲートウェイの設定に関連したすべての情報が収められています。ゲートウェイをインストールする場合、デフォルトの値を選択すると、「default」という名前のデフォルトゲートウェイプロファイルが作成されます。デフォルトプロファイルに相当する設定ファイルは、次の場所にあります。/etc/opt/SUNWportal/platform.conf.default

/etc/opt/SUNWportal は、すべての platform.conf.* ファイルが格納されるデフォルトの場所です。platform.conf ファイルの詳細については、「platform.conf ファイルの概要」を参照してください。

プロファイルを操作するときは、次の作業を実行できます。

複数のプロファイルを作成して、各プロファイルに属性を定義します。また、必要に応じてこれらのプロファイルを異なる複数のゲートウェイに割り当てます。
同じプロファイルを、複数のマシン上にあるゲートウェイに割り当てます。
異なる複数のプロファイルを、同じマシン上で稼動している単一のゲートウェイの複数のインスタンスに割り当てます。

注意 –

同じマシン上で稼動するゲートウェイの複数のインスタンスには、同じプロファイルを割り当てないでください。このように設定すると、ポート番号が同じになることにより競合が発生します。

また、同じゲートウェイに作成された複数のプロファイルに、同じポート番号を指定しないでください。同じゲートウェイの複数のインスタンスを同じポートで実行すると、競合が発生します。

複数のゲートウェイインスタンスの作成

複数のゲートウェイインスタンスの作成については、『Sun Java System Portal Server 7.2 Installation and Configuration Guide』の第 4 章「Installing and Configuring a Gateway With Portal Server」を参照してください。

マルチホームゲートウェイのインスタンスの作成

マルチホームゲートウェイのインスタンスとは、1 つの Portal Server 上に作成された複数のゲートウェイです。これらのインスタンスを作成するには、platform.conf ファイルを次のように変更します。

gatewaybindipaddress = 0.0.0.0

同じ LDAP を使用するゲートウェイインスタンスの作成

最初のゲートウェイを作成したあとで、同じ LDAP を使用する複数のゲートウェイを作成する場合は、次の操作を行います。

次の部分を参照しながら、/etc/opt/SUNWam/config/ の AMConfig-instance-name.properties を、最初にインストールしたゲートウェイインスタンスと一致するように変更します。

「同じ LDAP を使用するゲートウェイインスタンスを作成する」を参照してください。

ゲートウェイの再起動

通常はゲートウェイを再起動する必要はありません。再起動が必要なのは、次のいずれかに該当する場合だけです。

新規プロファイルを作成し、新しいプロファイルをゲートウェイに割り当てる必要がある場合
既存のプロファイルの属性を修正し、変更を有効にする必要がある場合
OutOfMemory エラーなどによりゲートウェイがクラッシュする場合
ゲートウェイが応答を停止し、要求を一切処理しない場合

ゲートウェイウォッチドッグの設定

ウォッチドッグがゲートウェイを監視する間隔を設定することができます。ウオッチドッグを開始または停止するには、次のコマンドを実行します。./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|offこの間隔は、デフォルトでは 60 秒に設定されています。この値を変更する場合は、crontab ユーティリティーで次の行を編集します。

0-59 * * * * gateway-install-root/SUNWportal/bin/
/var/opt/SUNWportal/.gw. 5 > /dev/null 2>&1

crontab のエントリを設定する方法については、crontab のマニュアルページを参照してください。

仮想ホストの指定

仮想ホストとは、同じマシンの IP とホスト名をポイントする追加のホスト名のことです。たとえば、ホスト名 abc がホスト IP アドレス 192.155.205.133 をポイントしている場合には、同じ IP アドレスをポイントする別のホスト名 cde を追加できます。

Access Manager へアクセスするプロキシの設定

ゲートウェイが、Portal Server に配備されている SRA コア (RemoteConfigServlet) にアクセスするために使用するプロキシホストを指定することができます。このプロキシは、Portal Server および Access Manager にアクセスするためにゲートウェイが使用します。「プロキシを指定する」を参照してください。

platform.conf ファイルの概要

platform.conf ファイルは、デフォルトでは次の場所にあります。/etc/opt/SUNWportal

platform.conf ファイルには、ゲートウェイが必要とする詳細情報が収められています。ここでは、サンプルの platform.conf ファイルを提示し、すべてのエントリについて説明します。

マシン固有の詳細を設定ファイルにすべて格納しているため、複数のマシンで実行するゲートウェイが共通のプロファイルを共有できるという利点があります。

次に platform.conf ファイルのサンプルを示します。

Tue May 30 11:51:23 IST 2006
debug.com.sun.portal.rewriter.original.level=INFO
gateway.favicon=
gateway.bindipaddress=10.12.154.236
debug.com.sun.portal.sra.rproxy.toFromServer.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromServer.%u.%g.log
gateway.port=443
rewriterproxy.jvm.flags=-ms64m -mx128m
portal.server.instance=default
debug.com.sun.portal.handler.java.util.logging.FileHandler.filter=
gateway.jdk.dir=/usr/jdk/entsys-j2se
gateway.ignoreURIList=/MSOffice/cltreq.asp,/_vti_bin/owssvr.dll
debug.com.sun.portal.rewriter.rest.level=INFO
gateway.trust_all_server_certs=true
debug.com.sun.portal.handler.java.util.logging.FileHandler.append=true
gateway.cdm.cacheCleanupTime=300000
gateway.httpurl=
debug.com.sun.portal.handler.java.util.logging.FileHandler.count=1
gateway.jvm.classpath=
debug.com.sun.portal.setserverlogs=false
gateway.protocol=https
debug.com.sun.portal.sra.rproxy.toFromServer=java.util.logging.FileHandler
rewriterproxy.jvm.classpath=
gateway.enable.customurl=false
debug.com.sun.portal.sra.rproxy.toFromBrowser=java.util.logging.FileHandler
debug.com.sun.portal.handler.java.util.logging.FileHandler.formatter=com.sun.portal.
log.common.PortalLogFormatter
debug.com.sun.portal.sra.rproxy.toFromBrowser.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/Gateway.toFromBrowser.%u.%g.log
debug.com.sun.portal.level=INFO
debug.com.sun.portal.rewriter.unaffected.separatefile=true
gateway.enable.accelerator=false
debug.com.sun.portal.rewriter.original.separatefile=true
gateway.virtualhost=nicp236.india.sun.com 10.12.154.236
debug.com.sun.portal.stacktrace=true 
gateway.host=nicp236.india.sun.com
debug.com.sun.portal.handler.java.util.logging.FileHandler.pattern=
/var/opt/SUNWportal/logs/sra/default/%logger.%sraComponentType.%u.%g.log
gateway.certdir=/etc/opt/SUNWportal/cert/default
gateway.sockretries=3
gateway.allow.client.caching=true
debug.com.sun.portal.rewriter.unaffected.level=INFO
debug.com.sun.portal.rewriter.uriinfo.separatefile=true
log.config.check.period=2000
debug.com.sun.portal.rewriter.rewritten.level=INFO
gateway.userProfile.cacheSize=1024
debug.com.sun.portal.rewriter.rulesetinfo.level=INFO
netletproxy.jvm.classpath=
gateway.userProfile.cacheSleepTime=60000
debug.com.sun.portal.rewriter.uriinfo.level=INFO
debug.com.sun.portal.rewriter.rest.separatefile=true
gateway.notification.url=notification
debug.com.sun.portal.rewriter.rulesetinfo.separatefile=true
gateway.logdelimiter=&&
gateway.ignoreServerList=false
gateway.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.handler.java.util.logging.FileHandler.limit=5000000
gateway.dsame.agent=http\://sunone216.india.sun.com\:8080/portal/RemoteConfigServlet
gateway.httpsurl=
gateway.retries=6
gateway.userProfile.cacheCleanupTime=300000
gateway.logging.password=X03MO1qnZdYdgyfeuILPmQ\=\= UX9x0jIua3hx1YOVRG/TLg\=\=
netletproxy.jvm.flags=-ms64m -mx128m
debug.com.sun.portal.rewriter.rewritten.separatefile=true
gateway.user=noaccess
gateway.external.ip=10.12.154.236
debug.com.sun.portal.handler=java.util.logging.FileHandler
gateway.cdm.cacheSleepTime=60000
rewriterproxy.accept.from.gateways=
rewriterproxy.checkacl=false

次の表は、platform.conf ファイルのすべてのフィールドと、その説明を示しています。

表 2–1 ファイルのプロパティー


エントリ	デフォルト値	説明
`gateway.user`	noaccess	ゲートウェイは、このユーザーとして実行されます。ゲートウェイは root として起動する必要があり、初期化のあと、root 権限を失いこのユーザーになります。
`gateway.jdk.dir`		ゲートウェイが使用する JDK ディレクトリの場所。
`gateway.dsame.agent`		ゲートウェイが起動中にそのプロファイルを取得するために通信する Access Manager の URL。
`portal.server.protocol` `portal.server.host` `portal.server.port`		デフォルトの Portal Server が使用しているプロトコル、ホスト、およびポート。
`gateway.protocolgateway. hostgateway.port`		ゲートウェイのプロトコル、ホスト、およびポート。これらの値は、インストール時に指定したモードおよびポートと同じです。これらの値は通知 URL の作成に使用されます。
`gateway. trust_all_server_certs`	true	ゲートウェイがすべてのサーバーの証明書を信頼する必要があるか、またはゲートウェイ認証データベースの証明書のみを信頼するべきかを指定します。
`gateway. trust_all_server_cert_domains`	false	ゲートウェイとサーバーの間で SSL 通信が行われるとき、サーバーの証明書がゲートウェイに提示されます。デフォルトでは、ゲートウェイはサーバーのホスト名がサーバーの証明書 CN と同じであるかどうかを検査します。この属性値が true に設定されている場合、ゲートウェイは受け取ったサーバーの証明書に対するドメインチェックを無効にします。
`gateway.virtualhost`		ゲートウェイマシンに複数のホスト名が設定されている場合、このフィールドで別の名前およびアイデンティティープロバイダアドレスを指定できます。
`gateway.virtualhost. defaultOrg=org`		ユーザーがログインするデフォルトの org を指定します。たとえば、仮想ホストフィールドのエントリが次のようになっていると仮定します。 `gateway.virtualhost=test.com employee.test.com` `Managers.test.com` この場合、デフォルトの org エントリは次のようになります。 `test.com.defaultOrg = o=root,dc=test,dc=com` `employee.test.com.defaultOrg = o=employee,dc=test,dc=com` `Manager.test.com.defaultOrg = o=Manager,dc=test,dc=com` ユーザーは `https://manager.test.com` を使用して、`https://test.com/o=Manager,dc=test,dc=com` ではなくマネージャーの org にログインできます。注 – virtualhost と defaultOrg は `platform.conf file` ファイルでは大文字と小文字が区別されますが、URL で使用する場合は区別されません。
`gateway.notification.url`		ゲートウェイのホスト、プロトコル、およびポートの組み合わせが、通知 URL の作成に使用されます。これは Access Manager からセッション通知を受け取るときに使用されます。 notification URL が組織名と一致しないことを確認します。通知 URL が組織名と一致する場合、その組織に接続しようとするとログインページではなく空のページが表示されます。
`gateway.retries`		ゲートウェイが起動時に Portal Server にアクセスを試みる回数。
`gateway.debug`	`error`	ゲートウェイのデバッグレベルを設定します。デバッグログファイルの場所は、`debug-directory/files` です。デバッグファイルの場所は、`gateway.debug.dir` エントリで指定されます。次のデバッグレベルがあります。 error: 重要なエラーのみがデバッグファイルにログとして記録される。このようなエラーが発生すると、通常はゲートウェイの機能が停止する。 warning: 警告メッセージがログとして記録される。 message: すべてのデバッグメッセージがログとして記録される。 on: すべてのデバッグメッセージがコンソールに表示される。次のデバッグファイルがあります。 `srapGateway.gateway-profile-name` : ゲートウェイデバッグメッセージを格納する。 `Gateway_to_from_server.gateway-profile-name` : メッセージモードの場合、ゲートウェイと内部サーバーの間のすべての要求と応答のヘッダーがこのファイルに格納される。このファイルを生成するには、`/var/opt/SUNWportal/debug` ディレクトリの書き込み権を変更します。 `Gateway_to_from_browser.gateway-profile-name` : メッセージモードの場合、ゲートウェイとクライアントブラウザの間のすべての要求と応答のヘッダーがこのファイルに格納される。このファイルを生成するには、`/var/opt/SUNWportal/debug` ディレクトリの書き込み権を変更します。
`gateway.debug.dir`		すべてのデバッグファイルが生成されるディレクトリ。このディレクトリは、`gateway.user` 内のユーザーがファイルの書き込みを行うための十分な権限を必要とします。
`gateway.logdelimiter`		現在は使用されていません。
`gateway.external.ip`		複数の IP アドレスを持つマルチホームゲートウェイマシンでは、外部 IP アドレスをここで指定する必要があります。この IP は、ネットレットが FTP を実行するために使用されます。
`gateway.certdir`		証明書データベースの場所を指定します。
`gateway.allow.client.caching`	true	クライアントのキャッシングを許可または拒否します。許可する場合、クライアントのブラウザでは、スタティックページおよびイメージをキャッシュして (ネットワークトラフィックを低減することで) パフォーマンスを向上できます。拒否する場合、キャッシュは行われずセキュリティーは高まりますが、ネットワークの負荷が増えるのでパフォーマンスは低下します。
`gateway.userProfile.cacheSize`		ゲートウェイでキャッシュされるユーザープロファイルのエントリ数。エントリ数がこの値を超えると、キャッシュのクリーンアップが頻繁に再試行されます。
`gateway.userProfile. cacheSleepTime`		キャッシュクリーンアップのためのスリープ時間 (秒単位) を設定します。
`gateway.userProfile. cacheCleanupTime`		プロファイルエントリが削除されるまでの最大時間 (秒)。
`gateway.bindipaddress`		マルチホームマシンで、ゲートウェイがサーバーソケットをバインドする IP アドレス。すべてのインタフェースを待機するようにゲートウェイを設定するには、IP アドレスを `gateway.bindipaddress=0.0.0.0` に置き換えます。
`gateway.sockretries`	3	現在は使用されていません。
`gateway.enable.accelerator`	false	true に設定した場合、外部アクセラレータの使用が許可されます。
`gateway.enable.customurl`	false	true に設定した場合、管理者はゲートウェイがページを書き換えるためのカスタム URL を指定できます。
`gateway.httpurl`		ゲートウェイがページを書き換えるためのカスタム URL 用の HTTP 逆プロキシ URL。プロキシレットが有効の場合、このエントリを使用します。
`gateway.httpsurl`		ゲートウェイがページを書き換えるためのカスタム URL 用の HTTPS 逆プロキシ URL。プロキシレットが有効の場合、このエントリを使用しないでください。
`gateway.favicon`		`favicon.icon` ファイルに対する要求をゲートウェイがリダイレクトする URL。これは、Internet Explorer および Netscape 7.0 以降の「お気に入り」のアイコンとして使用されます。何も指定しない場合、ゲートウェイはファイルが見つからないことを意味する 404 メッセージをブラウザに返します。
`gateway.logging.password`		ゲートウェイがアプリケーションセッションの作成に使用する `amService-srapGateway` ユーザーの LDAP パスワード。暗号化された形式、プレーンテキストのいずれかを指定できます。
`http.proxyHost`		このプロキシホストが Portal Server へのアクセスに使用されます。
`http.proxyPort`		Portal Server へのアクセスに使用されるホスト用のポート。
`http.proxySet`		プロキシホストが必要な場合は、このプロパティーを true に設定します。false に設定すると、`http.proxyHost` および `http.proxyPort` は無視されます。
`portal.server`.`instance`		このプロパティーの値には、対応する `/etc/opt/SUNWam/config/AMConfig`-`instance-name`.properties ファイルを指定します。この値がデフォルトの場合は、`AMConfig.properties` をポイントします。
`gateway.cdm.cacheSleepTime`	60000	クライアント検出モジュールの応答で、Access Manager からゲートウェイに送信されるキャッシュのタイムアウト値。
`gateway.cdm.cacheCleanupTime`	300000	クライアント検出モジュールの応答で、Access Manager からゲートウェイに送信されるキャッシュのタイムアウト値。
`netletproxy.port`	10555	ネットレットプロキシデーモンは、このポートで要求を待機します。
`rewriterproxy.port`	10555	リライタプロキシデーモンは、このポートで要求を待機します。
`gateway.ignoreServerList`	false	true に設定した場合、Access Manager サーバーの URL は `AMConfig.properties` ファイルで指定した値を使用して作成されます。Access Manager サーバーがロードバランサの背後にある場合、このプロパティーを true に設定します。
`rewriterproxy.accept.from.gateways`		これは、リライタプロキシでの要求の受け入れを可能にする IP アドレスのリストです。HTTP モードと HTTPS モードの両方で機能します。これはセキュリティーを高める目的で使用されます。このリストのアドレスからの要求のみが受け入れられ、その他の要求は一切処理されません。各 IP アドレスをコンマで区切って指定できます。デフォルト値は空で、その場合は旧バージョンモードとして扱われます。つまり、リライタプロキシへのすべての要求が受け入れられます。
`rewriterproxy.checkacl=`	false	このプロパティーが有効になっている場合、リライタプロキシは、ゲートウェイと同じように ACL の値をチェックします。旧バージョンモードの値は false です。true に設定すると、リライタプロキシは指定された DN で、URL をゲートウェイアクセスサービスに指定された値と照合し、リストの設定に従って要求を許可または拒否します。この値は、HTTP モードと HTTPS モードの両方で機能します。

Web プロキシの使用

SUN 以外の Web プロキシを使用して HTTP リソースにアクセスするように、ゲートウェイを設定できます。Web プロキシは、クライアントとインターネットの間に設置されます。

Web プロキシの設定

ドメインおよびサブドメインごとに異なるプロキシを使用できます。これらのエントリから、特定のドメインの特定のサブドメインへのアクセスに使用するプロキシがゲートウェイに伝えられます。ゲートウェイで指定したプロキシ設定は次のように機能します。

ゲートウェイサービスの「ドメインとサブドメインのプロキシ」フィールドで、必要なプロキシとドメインおよびサブドメインのリストを作成します。
「プロキシを使用する」オプションを選択すると、次のような設定になります。
- 指定されたホストに、「ドメインとサブドメインのプロキシ」フィールドで指定したプロキシが使用されます。
- 「ドメインとサブドメインのプロキシ」リストで指定したドメインとサブドメイン内の、特定の URL に直接接続できるようにするには、「Web プロキシを使用しない URL」フィールドにその URL を指定します。
「プロキシを使用する」オプションを選択しない場合は、次のような設定になります。
- 「ドメインとサブドメインのプロキシ」フィールドで指定したドメインとサブドメイン内の特定の URL にプロキシを使用するには、「Web プロキシを使用しない URL」リストにその URL を指定します。
  
  「プロキシを使用する」オプションが無効になっていても、「Web プロキシを使用する URL」リスト内の URL への接続にはプロキシが使用されます。これらの URL のプロキシは、「ドメインとサブドメインのプロキシ」リストから取得されます。
  
  次の図は、ゲートウェイサービスのプロキシ設定に基づいて Web プロキシ情報が解決される手順を示しています。
  
  「Web プロキシの設定」では、「プロキシを使用する」が選択され、「Web プロキシを使用しない URL」リストに要求された URL が含まれている場合、ゲートウェイは指定されたホストに直接接続します。
  
  「プロキシを使用する」が選択され、「Web プロキシを使用しない URL」リストに要求された URL が含まれていない場合、ゲートウェイは指定されたプロキシを経由してホストに接続します。プロキシが指定されている場合は、「ドメインとサブドメインのプロキシ」リスト内でプロキシが検索されます。
  
  「プロキシを使用する」が無効で、「Web プロキシを使用する URL」リストに要求された URL が含まれている場合、ゲートウェイは「ドメインとサブドメインのプロキシ」リストのプロキシ情報を使用して目的のホストに接続します。
  
  「プロキシを使用する」が無効で、「Web プロキシを使用する URL」リストに要求された URL が含まれていない場合、ゲートウェイは指定されたホストに直接接続します。
  
  前述したいずれの条件も満たさず、直接接続が不可能な場合は、ゲートウェイは接続不可を伝えるエラーを表示します。

注 –

標準のポータルデスクトップのブックマークチャネルを通じて URL にアクセスする場合、前述したいずれの条件にも合わない場合は、ゲートウェイはブラウザにリダイレクトを送信します。ブラウザは独自のプロキシ設定を使用して URL にアクセスします。

構文

domainname [web_proxy1:port1]|subdomain1 [web_proxy2:port2]|

例

sesta.com wp1:8080|red wp2:8080|yellow|* wp3:8080

* はすべてに一致するワイルドカードです。

各表記の意味は次のとおりです。

sesta.com はドメイン名、wp1 はポート 8080 にアクセスするプロキシです。

red はサブドメイン、wp2 はポート 8080 にアクセスするプロキシです。

yellow はサブドメインです。プロキシが指定されていないため、ドメインに指定されたプロキシ、つまりポート 8080 の wp1 が使用されます。

* は、ほかのすべてのサブドメインがポート 8080 で wp3 を使用する必要があることを表します。

注 –

デフォルトでは、ポートを指定しない場合ポート 8080 が使用されます。

Web プロキシ情報の処理

クライアントが特定の URL へのアクセスを試みると、URL のホスト名が「ドメインとサブドメインのプロキシ」リスト内のエントリと照合されます。指定されたホスト名でもっとも長いサフィックスに一致するエントリが選ばれます。たとえば、ホスト名 host1.sesta.com が要求されているとします。一致するエントリが見つかるまで、次の検索が順に行われます。

「ドメインとサブドメインのプロキシ」リストで host1.sesta.com がスキャンされます。一致するエントリが見つかると、このエントリに指定されたプロキシがホストの接続に使用されます。
見つからなかった場合、リストで *.sesta.com がスキャンされます。エントリが見つかると、対応するプロキシが使用されます。
見つからなかった場合、リストで sesta.com がスキャンされます。エントリが見つかると、対応するプロキシが使用されます。
見つからなかった場合、リストで *.com がスキャンされます。エントリが見つかると、対応するプロキシが使用されます。
見つからなかった場合、リストで com がスキャンされます。エントリが見つかると、対応するプロキシが使用されます。
見つからなかった場合、リストで * がスキャンされます。エントリが見つかると、対応するプロキシが使用されます。
一致するエントリが見つからなかった場合、直接接続が試みられます。

「ドメインとサブドメインのプロキシ」リストに次のようなエントリがあるとします。

com p1| host1 p2 | host2 | * p3
sesta.com p4 | host5 p5 | * p6
florizon.com | host6
abc.sesta.com p8 | host7 p7 | host8 p8 | * p9
host6.florizon.com p10
host9.sesta.com p11
siroe.com | host12 p12 | host13 p13 | host14 | * p14
siroe.com | host15 p15 | host16 | * p16
* p17

ゲートウェイは、次の表に示すように、これらのエントリを内部的に 1 つのテーブルにマッピングします。

表 2–2 「ドメインとサブドメインのプロキシ」リストのエントリのマッピング


番号	「ドメインとサブドメインのプロキシ」リストのエントリ	プロキシ	説明
1	com	p1	リストで指定されたプロキシ
2	host1.com	p2	リストで指定されたプロキシ
3	host2.com	p1	host2 に対してプロキシが指定されないため、ドメインのプロキシが使用されます。
4	*.com	p3	リストで指定されたプロキシ
5	sesta.com	p4	リストで指定されたプロキシ
6	host5.sesta.com	p5	リストで指定されたプロキシ
7	*.sesta.com	p6	リストで指定されたプロキシ
8	florizon.com	直接	詳細はエントリ 14 の説明を参照
9	host6.florizon.com	–	詳細はエントリ 14 の説明を参照
10	abc.sesta.com	p8	リストで指定されたプロキシ
11	host7.abc.sesta.com	p7	リストで指定されたプロキシ
12	host8.abc.sesta.com	p8	リストで指定されたプロキシ
13	*.abc.sesta.com	p9	リストで指定されたプロキシ`abc.sesta.com` ドメインの `host7` と `host8` 以外のすべてのホストについては、`p9` がプロキシとして使用されます。
14	host6.florizon.com	p10	エントリ 9 と同じエントリ。エントリ 9 は直接接続を指定するのに対し、このエントリはプロキシ p10 の使用を指定します。このような 2 つのエントリがある場合、プロキシ情報のあるエントリが有効なエントリと見なされます。もう 1 つのエントリは無視されます。
15	host9.sesta.com	p11	リストで指定されたプロキシ
16	siroe.com	直接	`siroe.com` に対して指定されるプロキシがないため、直接接続が試みられます。
17	host12.siroe.com	p12	リストで指定されたプロキシ
18	host13.siroe.com	p13	リストで指定されたプロキシ
19	host14.siroe.com	直接	`host14` に対して指定されるプロキシがないため、直接接続が試みられます。
20	*.siroe.com	p14	エントリ 23 の説明を参照
21	host15.siroe.com	p15	リストで指定されたプロキシ
22	host16.siroe.com	直接	host16 または `siroe.com` に対して指定されるプロキシがないため、直接接続が試みられます。
23	*.siroe.com	p16	エントリ 20 に類似していますが、指定されるプロキシが異なります。このような場合、ゲートウェイの正確な動作がわかりません。2 つのプロキシのいずれかが使用されます。
24	*	p17	要求された URL に一致するエントリが存在しない場合、プロキシとして `p17` が使用されます。

ヒント –

「ドメインとサブドメインのプロキシ」リストでは、プロキシエントリを「|」記号で区切らずに、個々のエントリをリスト内の各行に配置できます。たとえば、次のように表記されるエントリがあるとします。

sesta.com p1 | red p2 | * p3

この情報は次のように指定できます。

sesta.com p1
red.sesta.com p2
*.sesta.com p3

このようなリスト形式にすると、反復されたエントリやその他のあいまいなエントリを追跡しやすくなります。

ドメインとサブドメインのプロキシリストに基づく書き換え

リライタも、「ドメインとサブドメインのプロキシ」リストのエントリを使用します。リライタは、ドメインが「ドメインとサブドメインのプロキシ」リストのドメインに一致するすべての URL を書き換えます。

注意 –

「ドメインとサブドメインのプロキシ」リストのエントリ * は、書き換えの対象と見なされません。たとえば、エントリ 24 は書き換えの対象になりません。

リライタについては、第 4 章「リライタの操作」を参照してください。

デフォルトのドメインとサブドメイン

URL の最終ホストが完全修飾名になっていない場合、完全修飾名に到達するためにデフォルトのドメインおよびサブドメインが使用されます。

管理コンソールの「デフォルトのドメイン」フィールドに、次のエントリが設定されていると仮定します。

red.sesta.com

注 –

「ドメインとサブドメインのプロキシ」リストには、対応するエントリが必要です。

前述した例では、sesta.com がデフォルトのドメイン、デフォルトのサブドメインは red です。

要求された URL が host1 の場合、このエントリはデフォルトのドメインとサブドメインを使用して host1.red.sesta.com として解決されます。「ドメインとサブドメインのプロキシ」リストに host1.red.sesta.com があるかどうかが確認されます。

自動プロキシ設定の使用

「ドメインとサブドメインのプロキシ」リストの情報を無視するには、自動プロキシ設定機能を有効にします。

プロキシ自動設定 (PAC) ファイルを使用するときは、次の点に注意してください。

Portal Server、ゲートウェイ、ネットレット、およびプロキシレットは、Rhino ソフトウェアを使用して PAC ファイルを解析します。SUNWrhino パッケージは、Java Enterprise System アクセサリ CD からインストールできます。

このパッケージに含まれている js.jar ファイルは、/usr/share/lib ディレクトリに存在している必要があります。このディレクトリは、ゲートウェイおよび Portal Server マシンの webserver/appserver クラスパスに追加してください。このクラスパスに見つからなかった場合、Portal Server、ゲートウェイ、ネットレット、およびプロキシレットは PAC ファイルを解析できません。
ゲートウェイマシンの $JRE_HOME/lib/ext ディレクトリに js.jar が存在する必要があります。このファイルが存在しない場合、ゲートウェイは PAC ファイルを解析できません。
ゲートウェイは起動時に、ゲートウェイプロファイルの「自動プロキシ設定ファイルの位置」フィールドに指定されている場所から PAC ファイルを取得します。
ゲートウェイは、URLConnection API を使用してこの場所にアクセスします。ゲートウェイにアクセスするようにプロキシを設定しなければならないときは、プロキシを次のように設定します。
1. コマンド行で、次のファイルを編集します。
  
  /etc/opt/SUNWportal/platform.conf.gateway-profile-name
2. 次のエントリを追加します。
  
  http.proxyHost= web-proxy-hostname
  
  http.proxyPort= web-proxy-port
  
  http.proxySet=true
3. 指定のプロキシを使用するために、ゲートウェイを再起動します。
  
  ./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>
PAC ファイルの初期化に失敗した場合は、ゲートウェイは「ドメインとサブドメインのプロキシ」リストの情報を使用します。
PAC ファイルから空白文字列または「NULL」が返される場合、ゲートウェイはそのホストがイントラネットに属していないと判断します。これは、「ドメインとサブドメインのプロキシ」に含まれないホストの扱いと似ています。

ゲートウェイにホストへの直接接続を使用させたい場合は、「DIRECT」を返します。「DIRECT または NULL のいずれかが返される例」を参照してください。
複数のプロキシが指定されている場合、ゲートウェイは最初に返されるプロキシだけを使用します。ホストに指定されている複数のプロキシの間で、フェイルオーバーや負荷分散は行われません。
ゲートウェイは SOCKS プロキシを無視して直接接続を試み、ホストがイントラネットの一部であると解釈します。
イントラネットの一部に含まれないホストへのアクセスに使用するプロキシを指定するには、STARPROXY というプロキシタイプを使用します。このプロキシタイプは、PAC 形式のファイル拡張子で、ゲートウェイプロファイルの「ドメインとサブドメインのプロキシ」セクションに指定される * proxyHost:port エントリと似ています。「STARPROXY が返される例」を参照してください。

サンプル PAC ファイルの使用

次の例は、「ドメインとサブドメインのプロキシ」リストに含まれる URL と、それに対応する PAC ファイルを示しています。

DIRECT または NULL のいずれかが返される例

次のプロキシをドメインとサブドメインに使用する場合を考えます。

*intranet1.com proxy.intranet.com:8080

intranet2.com proxy.intranet1.com:8080

対応する PAC ファイルは次のようになります。

// Start of the PAC File
function FindProxyForURL(url, host) {
         if (dnsDomainIs(host, ".intranet1.com")) {
             return "DIRECT";
         }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080";
          }
          return "NULL";
}
//End of the PAC File

STARPROXY が返される例

次のプロキシをドメインとサブドメインに使用する場合を考えます。

intranet1.com

intranet2.com.proxy.intranet1.com:8080

internetproxy.intranet1.com:80

対応する PAC ファイルは次のようになります。

// Start of the PAC File
function FindProxyForURL(url, host) {
          if (dnsDomainIs(host, ".intranet1.com")) {
              return "DIRECT";
          }
          if (dnsDomainIs(host, ".intranet2.com")) {
              return "PROXY proxy.intranet1.com:8080;" +
                  "PROXY proxy1.intranet1.com:8080";
          }
          return "STARPROXY internetproxy.intranet1.com:80";
}
//End of the PAC File

この場合、要求が .intranet2.com ドメイン内のホストに対するものであれば、ゲートウェイは proxy.intranet1.com:8080 にアクセスします。proxy.intranet1.com:8080 がダウンしている場合、要求は失敗します。ゲートウェイは、フェイルオーバーを行わず、proxy1.intranet1.com:8080 にアクセスします。

PAC ファイルの場所の指定

PAC ファイルの場所を指定するための形式は、その場所により次のようになります。

PAC ファイルが Web サーバーに常駐している場合、PAC URL は次のようになります。

http://hostname/pacfile_name .pac
PAC ファイルがローカルファイルの場合 (たとえば、c:\pacfile\sample.pac)、Java 1.4.1_x では PAC URL を次のように入力します。

file://c:/pacfile/sample.pac
PAC ファイルがローカルファイルの場合 (たとえば、c:\pacfile\sample.pac)、Java 1.4.2_x では PAC URL を次のように入力します。

file:///c:/pacfile/sample.pac

個別のセッションにおけるサービスの追加

個別のセッションで Portal Server サービスを追加する場合は、次の操作を行います。

管理コンソールの「ゲートウェイ」 > 「コア」の下に Portal Server を一覧表示する。
「ゲートウェイ」 > 「セキュリティー」の下にある「非認証 URL」に Portal Server の URL を一覧表示する。

ネットレットプロキシの使用

ネットレットパケットはゲートウェイで解読され、宛先サーバーに送られます。ただし、ゲートウェイはすべてのネットレット接続先ホストにアクセスする場合、非武装ゾーン (DMZ) とイントラネット間のファイアウォールを経由する必要があります。このように設定するには、ファイアウォールで多くのポートを開かなければなりません。ネットレットプロキシを使用することで、ファイアウォールで開かれるポートの数を最小化することができます。

ネットレットプロキシは、ゲートウェイを経由してクライアントからのセキュリティー保護されたトンネルをイントラネット内のネットレットプロキシまで拡張することで、ゲートウェイとイントラネット間のセキュリティーを補強します。プロキシを使用すると、ネットレットパケットがネットレットプロキシにより解読され、送信先に送られます。

ネットレットプロキシを使用する利点を次に示します。

セキュリティーのレイヤーを補強します。
配備サイズが大きな環境で、ゲートウェイから内部ファイアウォールに必要以上の IP アドレスおよびポートを使用しないようにします。
ゲートウェイと Portal Server 間で開かれるポートの数を 1 つに制限します。このポート数はインストール時に設定できます。
「ネットレットプロキシの使用」の「ネットレットプロキシをインストールした場合」に示すように、クライアントとゲートウェイ間のセキュリティー保護されたチャネルを Portal Server まで延長します。ネットレットプロキシはデータの暗号化によってセキュリティーを改善しますが、システムリソースの使用を増やす場合があります。ネットレットプロキシのインストールについては、『Sun Java System インストールガイド』を参照してください。

次の作業を実行できます。

Portal Server ノードまたは別のノードでネットレットプロキシをインストールします。
複数のネットレットプロキシをインストールし、それらを管理コンソールで単一のゲートウェイに対して設定します。これは負荷分散に役立ちます。
単一のマシンでネットレットプロキシの複数のインスタンスを設定します。
ゲートウェイの複数のインスタンスに対して、ネットレットプロキシの単一のインストールを設定します。
Web プロキシを通じたネットレットトンネリング

ネットレットプロキシをインストールした場合とインストールしない場合のゲートウェイと Portal Server の 3 つの実装例を示します。クライアント、2 つのファイアウォール、2 つのファイアウォールの間にあるゲートウェイ、Portal Server、およびネットレット宛先サーバーから構成されます。

最初の例では、ネットレットプロキシをインストールしていないゲートウェイと Portal Server を示しています。データの暗号化はクライアントとゲートウェイの間だけで行われます。ネットレット接続の要求があるたびに、2 番目のファイアウォールでポートが開かれます。

2 番目の例では、ゲートウェイと、ネットレットプロキシがインストールされている Portal Server を示しています。データの暗号化はクライアントから Portal Server までのすべての区間に拡張されています。すべてのネットレットがネットレットプロキシを通じてルーティングされているため、ネットレット要求に対して 2 番目のファイアウォールで開く必要があるのは 1 つのポートのみです。

3 番目の例では、ネットレットプロキシが別のノードにインストールされている Portal Server とゲートウェイを示しています。別のノードにネットレットプロキシをインストールすると、Portal Server ノードの負荷が減少します。この場合も、2 番目のファイアウォールで開く必要があるのは 2 つのポートのみです。1 つのポートは Portal Server への要求を処理し、もう 1 つのポートはネットレットの要求をネットレットプロキシサーバーにルーティングします。

図 2–1 ネットレットプロキシの実装

ネットレットプロキシの有効化

ネットレットプロキシは、Portal Server 管理コンソールを使用して、ゲートウェイサービスから有効にします。

ネットレットプロキシの再起動

プロキシが何らかの理由で強制終了した場合に再起動するように、ネットレットプロキシを設定することができます。ネットレットプロキシを監視し、ネットレットプロキシが停止したときに再起動するようにウォッチドッグプロセスをスケジューリングできます。

ネットレットプロキシは手動で再起動することもできます。手順については、「ネットレットプロキシを再起動する」を参照してください。

ネットレットプロキシのウォッチドッグを設定する

ウォッチドッグがネットレットプロキシの状態を監視する間隔を設定することができます。この間隔は、デフォルトでは 60 秒に設定されています。この間隔を変更するには、crontab ファイルに次の行を追加します。

0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

注 –

ウオッチドッグを開始または停止するには、次のコマンドを実行します。./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off

リライタプロキシの使用

リライタプロキシは、イントラネット上にインストールされます。ゲートウェイは、コンテンツを直接取得せずにすべての要求をリライタプロキシに送信し、リライタプロキシはコンテンツを取得してゲートウェイに返します。

リライタプロキシを使用する利点を次に示します

ゲートウェイとサーバー間にファイアウォールが存在する場合、ファイアウォールが開放する必要があるのは 2 つのポートのみです。1 つはゲートウェイとリライタプロキシの間のポート、もう 1 つはゲートウェイと Portal Server の間のポートです。
宛先サーバーが HTTPS をサポートせず、HTTP しかサポートしていなくても、ゲートウェイとインターネットの間の HTTP トラフィックはセキュリティー保護されます。

リライタプロキシを指定しない場合、いずれかのイントラネットコンピュータにアクセスしようとすると、ゲートウェイコンポーネントによりイントラネットコンピュータに直接つながります。

リライタプロキシをロードバランサとして使用する場合は、リライタの platform.conf.instance_name がロードバランサ URL をポイントしている必要があります。また、ロードバランサのホストを Portal Servers リストに指定してください。

ゲートウェイインスタンスごとに (Portal Server ノード上でなくてもかまわない) リライタプロキシの複数インスタンスがある場合は、platform.conf ファイルに、リライタプロキシに対して 1 つのポートエントリを指定するのではなく、host-name:port の形式でリライタプロキシごとに詳細を指定します。

リライタプロキシのインスタンスの作成

リライタプロキシの新しいインスタンスを Portal Server ノードに作成するときは、rwpmultiinstance スクリプトを使用します。このスクリプトは、ゲートウェイプロファイルが作成されたあとで実行します。

「リライタプロキシインスタンスを作成する」を参照してください。

リライタプロキシの有効化

リライタプロキシを有効化するときは、Access Manager 管理コンソールの「SRA 設定」の下にある「ゲートウェイ」サービスを使用します。

リライタプロキシの再起動

プロキシが何らかの理由で強制終了した場合に、リライタプロキシが再起動するように設定することができます。リライタプロキシを監視し、リライタプロキシが強制終了したときに再起動するようにウォッチドッグプロセスをスケジューリングできます。

リライタプロキシは手動で再起動することもできます。

「リライタプロキシを再起動する」を参照してください。

リライタプロキシのウォッチドッグの設定

ウォッチドッグがリライタプロキシの状態を監視する間隔を設定することができます。この間隔は、デフォルトでは 60 秒に設定されています。この間隔を変更するには、crontab ファイルに次の行を追加します。

0-59 * * * * rewriter-proxy-install-root /bin/checkgw /var/opt/SUNWportal/.gw 5 > /dev/null 2>&1

注 –

ウオッチドッグを開始または停止するには、次のコマンドを実行します。./psadmin sra-watchdog -u amadmin -f <password-file> -t <type> on|off

ゲートウェイでの逆プロキシの使用

プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。逆プロキシを配備するときに、負荷分散およびキャッシングが行われるように設定できます。

ゲートウェイの前にサードパーティーの逆プロキシがある配備の場合、応答は、ゲートウェイの URL ではなく逆プロキシの URL で書き換えられる必要があります。このためには、逆プロキシを有効化する必要があります。

「逆プロキシを有効化する」を参照してください。

クライアント情報の取得

ゲートウェイがいずれかの内部サーバーにクライアント要求を転送するときに、HTTP 要求に HTTP ヘッダーが追加されます。それらのヘッダーを使用して追加のクライアント情報を取得し、ゲートウェイの存在を検出することができます。

HTTP 要求ヘッダーを表示するには、platform.conf ファイル内のエントリを gateway.error=message に設定します。次に、サーブレット API から request.getHeader() を使用します。次の表は、HTTP ヘッダー内の情報を示しています。

表 2–3 HTTP ヘッダーの情報


ヘッダー	構文	説明
PS-GW-PDC	`X-PS-GW- PDC: true/false`	ゲートウェイで PDC が有効であるかどうかを示します。
PS-Netlet	`X-PS-Netlet:enabled=true/false`	ゲートウェイでネットレットが有効化されているか、それとも無効化されているかを示します。ネットレットが有効化されている場合は、暗号化オプションが生成され、ゲートウェイが HTTPS モード (`encryption=ssl`) または HTTP モード (`encryption=plain`) のどちらで実行されているかが示されます。次に例を示します。 `PS-Netlet: enabled=false` ネットレットは無効化されています。 `PS-Netlet: enabled=true; encryption=ssl` ネットレットは有効で、ゲートウェイは SSL モードで稼動しています。ネットレットが有効でない場合は、`encryption=ssl` または `encryption=plain` は生成されません。
PS-GW-URL	`X-PS-GW-URL: http(s)://gatewayURL(:port)`	クライアントが接続している URL を示します。ポートが標準ポートでない場合 (ゲートウェイが HTTP/HTTPS モードで稼動し、ポートが 80/443 でない場合など) は、`:port` が追加されます。
PS-GW-Rewriting-URL	`X-PS-GW-URL:` `http(s)://gatewayURL(:port)/[SessionInfo]`	ゲートウェイがすべてのページを書き換える URL を示します。ブラウザが Cookie をサポートする場合、このヘッダーの値は PS-GW-URL ヘッダーと同じです。ブラウザが Cookie をサポートしない場合は、次のようになります。接続先ホストが「ユーザーセッション Cookie を転送する URL」フィールドに含まれる場合は、ゲートウェイがページを書き換える実際の URL (符号化されたセッション ID 情報が含まれる) 接続先ホストが「ユーザーセッション Cookie を転送する URL」フィールドに含まれない場合は、`SessionInfo` 文字列は `$SessionID` となる注 – 認証ページからの応答のように、応答の過程でユーザーの Access Manager のセッション ID が変更された場合、ページは、それまでヘッダーに指定されていた値ではなくその値で書き換えられます。次に例を示します。ブラウザが Cookie をサポートする場合は、次のようになります。 PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/ ブラウザが Cookie をサポートせず、エンドサーバーが「ユーザーセッション Cookie を転送する URL」フィールドに含まれる場合は、次のようになります。 PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCustomEncodedValue/ ブラウザが Cookie をサポートしないが、エンドサーバーが「ユーザーセッション Cookie を転送する URL」フィールドに含まれない場合は、次のようになります。 PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/$SessionID
PS-GW-CLientIP	`X-PS-GW-CLientIP:` `IP`	ゲートウェイが `recievedSocket.getInetAddress().getHostAddress()` から取得した IP を示します。クライアントがゲートウェイに直接接続する場合、この値によって IP が特定されます。

認証連鎖の使用

認証連鎖することにより、通常の認証メカニズムより高いレベルのセキュリティーがもたらされます。ユーザーを複数の認証メカニズムで認証することができます。

ここでは、PDC (Personal Digital Certificate) 認証によってゲートウェイで認証連鎖を有効化する手順だけを説明します。PDC 認証を使用しない場合のゲートウェイでの認証連鎖については、『Access Manager 管理ガイド』を参照してください。

たとえば、PDC と Radius 認証モジュールを連鎖させると、ユーザーは標準のポータルデスクトップにアクセスするために 3 つのモジュールすべてについて認証が必要になります。

手順については、「既存の PDC インスタンスに認証モジュールを追加する」を参照してください。

注 –

PDC が有効になっていると、PDC が常に最初の認証モジュールとしてユーザーに提示されます。

ワイルドカード証明書の使用

ワイルドカード証明書は、ホストの完全修飾 DNS 名にワイルドカード文字を含む単一の証明書を受け付けます。

この証明書によって、同じドメイン内の複数のホストがセキュリティーで保護されます。たとえば、*.domain.com の証明書は abc.domain.com と abc1.domain.com に使用できます。この証明書は domain.com ドメイン内のすべてのホストに有効です。

ブラウザキャッシングの無効化

ゲートウェイコンポーネントは Web ブラウザのみを使用して任意の場所からバックエンド企業データへのセキュリティー保護されたアクセスを提供するため、クライアントが情報をローカルにキャッシュする必要はありません。

ゲートウェイを通じてリダイレクトされるページのキャッシングを無効にするには、そのゲートウェイの platform.conf ファイルの属性を修正します。

このオプションを無効にすると、ゲートウェイのパフォーマンスに影響する場合があります。標準のポータルデスクトップが再表示されるたびに、ブラウザがすでにキャッシュしているイメージを含めページが参照するすべてのデータをゲートウェイで取り出す必要があるためです。ただし、この機能を有効にしても、リモートアクセスされたセキュリティー保護されたコンテンツの足跡は、クライアントサイトでキャッシュとして残りません。この要因がパフォーマンスへの影響よりも重要な意味を持つのは、企業 IT の管理下にないインターネットカフェやその類のリモートロケーションから企業ネットワークにアクセスしている場合です。

「ブラウザキャッシングを無効にする」を参照してください。

ゲートウェイサービスのユーザーインタフェースのカスタマイズ

ここでは、編集可能な各種のゲートウェイプロパティーファイルについて説明します。

srapGateway.properties ファイルの編集

このファイルは、次の目的のために編集できます。

ゲートウェイの実行時に表示されるエラーメッセージをカスタマイズします。
- HTML-CharSets=ISO-8859-1 は、このファイルの作成に使用された文字セットを示しています。
- 中カッコで囲まれた番号 ({0} など) は、実行時に表示される値です。この番号に対応するラベルを変更できます。また、必要に応じてラベルを並べ替えることができます。番号とメッセージは関連付けられるため、表示されるメッセージにラベルが対応していることを確認してください。
ログ情報をカスタマイズします。

デフォルトでは、srapGateway.properties ファイルは portal-server-install-root/SUNWportal/locale ディレクトリ内にあります。ゲートウェイマシンに表示されるすべてのメッセージは、メッセージの言語にかかわりなく、このファイルに格納されます。

クライアントの標準のポータルデスクトップに表示されるメッセージの言語を変更するには、このファイルを portal-server-install-root/SUNWportal/srapGateway_<locale>.properties などの各ロケール用ファイルを変更します。

srapgwadminmsg.properties ファイルの編集

このファイルは、次の目的のために編集できます。

管理コンソールのゲートウェイサービスのボタンとして表示されるラベルをカスタマイズします。
ゲートウェイを設定しているときに表示される状況メッセージとエラーメッセージをカスタマイズします。

LDAP ディレクトリの共有

Portal Server と Access Manager サーバーの 2 つのインスタンスが同じ LDAP ディレクトリを共有している場合、それ以後のすべての Portal Server インスタンス、Access Manager インスタンス、およびゲートウェイインスタンスで LDAP ディレクトリが共有されます。「LDAP ディレクトリを共有する」を参照してください。

第 2 章 ゲートウェイの操作

ゲートウェイの概要

ゲートウェイプロファイルの作成

複数のゲートウェイインスタンスの作成

マルチホームゲートウェイのインスタンスの作成

同じ LDAP を使用するゲートウェイインスタンスの作成

ゲートウェイの再起動

ゲートウェイウォッチドッグの設定

仮想ホストの指定

Access Manager へアクセスするプロキシの設定

platform.conf ファイルの概要

Web プロキシの使用

Web プロキシの設定

構文

例

Web プロキシ情報の処理

ドメインとサブドメインのプロキシリストに基づく書き換え

デフォルトのドメインとサブドメイン

自動プロキシ設定の使用

サンプル PAC ファイルの使用

DIRECT または NULL のいずれかが返される例

STARPROXY が返される例

PAC ファイルの場所の指定

個別のセッションにおけるサービスの追加

ネットレットプロキシの使用

図 2–1 ネットレットプロキシの実装

ネットレットプロキシの有効化

ネットレットプロキシの再起動

ネットレットプロキシのウォッチドッグを設定する

リライタプロキシの使用

リライタプロキシのインスタンスの作成

リライタプロキシの有効化

リライタプロキシの再起動

リライタプロキシのウォッチドッグの設定

ゲートウェイでの逆プロキシの使用

クライアント情報の取得

認証連鎖の使用

ワイルドカード証明書の使用

ブラウザキャッシングの無効化

ゲートウェイサービスのユーザーインタフェースのカスタマイズ

srapGateway.properties ファイルの編集

srapgwadminmsg.properties ファイルの編集

LDAP ディレクトリの共有

第 2 章ゲートウェイの操作