| Sun ONE Portal Server, Secure Remote Access 6.2 管理者ガイド |
第 2 章
ゲートウェイこの章では、ゲートウェイのスムースな実行に必要な、ゲートウェイに関連する概念と情報について説明します。ゲートウェイの設定については、第 9 章「ゲートウェイの設定」を参照してください。
この章で説明する内容は次のとおりです。
ゲートウェイの概要ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティバリアとして機能します。ゲートウェイはリモートユーザーとの単一のインタフェースを通じて、内部 Web サーバーとアプリケーションサーバーのコンテンツを安全に提供します。
ゲートウェイプロファイルの作成ゲートウェイプロファイルには、ゲートウェイが待機するポート、SSL オプション、プロキシオプションなどのゲートウェイの設定に関連したすべての情報が収められています。
ゲートウェイをインストールする場合、デフォルトの値を選択すると「default」というデフォルトゲートウェイプロファイルが作成されます。デフォルトプロファイルに相当する設定ファイルは、次の場所にあります。
/etc/opt/SUNWps/platform.conf.default
/etc/opt/SUNWps は、すべての platform.conf.* ファイルが格納されるデフォルトの場所です。
platform.conf ファイルの内容についての詳細は、「platform.conf ファイルの概要」を参照してください。
次の処理を実行できます。
警告
同じマシン上で稼動するゲートウェイの複数のインスタンスに同じプロ ファイルを割り当てないでください。このような方法で割り当てると、同 じポート番号の間で衝突が生じます。
また、同じゲートウェイに作成された複数のプロファイルに、同じポート 番号を指定しないでください。同じゲートウェイの複数のインスタンスを 同じポートで実行すると、衝突が発生します。
ゲートウェイプロファイルを作成するには
- SunTM ONE Identity Server 管理コンソールに管理者としてログインします。
- 「サービス設定」タブを選択します。
- 「SRA 設定」の「ゲートウェイ」の隣の矢印をクリックします。
「ゲートウェイ」ページが右のパネルに表示されます。
- 「新規」をクリックします。
「新規ゲートウェイプロファイル作成」ページが表示されます。
- 新規ゲートウェイプロファイル名を入力します。
- ドロップダウンリストから、新規プロファイルの作成に使用するプロファイルを選択します。
デフォルトでは、新規プロファイルはパッケージ内の「default」プロファイルに基づいて作成されます。カスタムプロファイルを作成している場合、ドロップダウンリストからそのプロファイルを選択できます。新しいプロファイルは、選択したプロファイルのすべての属性を継承します。
- 「作成」をクリックします。
新規プロファイルが作成され、「ゲートウェイ」ページに戻ります。このページには、新しいプロファイルが表示されます。
- 変更を有効にするには、このゲートウェイプロファイル名でゲートウェイを再起動します。
portal-server-install-root/SUNWps/bin/gateway -n gateway-profile-name start
ゲートウェイの設定については、第 9 章「ゲートウェイの設定」を参照してください。
platform.conf ファイルの概要platform.conf ファイルは次の場所にあります。
/etc/opt/SUNWps
platform.conf ファイルには、ゲートウェイが必要とする詳細情報が収められています。ここでは、サンプルの platform.conf ファイルを提示し、すべてのエントリについて説明します。
マシン固有の詳細を設定ファイルにすべて格納しているため、複数のマシンで実行するゲートウェイが共通のプロファイルを共有できるという利点があります。
次に例を示します。
#
# Copyright 11/28/00 Sun Microsystems, Inc. All Rights Reserved.
# "@(#)platform.conf 1.38 00/11/28 Sun Microsystems"
#
gateway.user=noaccess
gateway.jdk.dir=/usr/java_1.3.1_06
gateway.dsame.agent=http://pserv2.iportal.com:8080/sunportal/Remote ConfigServlet
portal.server.protocol=http
portal.server.host=pserv2.iportal.com
portal.server.port=8080
gateway.protocol=https
gateway.host=siroe.india.sun.com
gateway.port=333
gateway.trust_all_server_certs=true
gateway.trust_all_server_cert_domains=false
gateway.virtualhost=siroe1.india.sun.com 10.13.147.81
gateway.virtualhost.defaultOrg=o=root,dc=test,dc=com
gateway.notification.url=/notification
gateway.retries=6
gateway.debug=error
gateway.debug.dir=/var/opt/SUNWps/debug
gateway.logdelimiter=&&
gateway.external.ip=10.12.147.71
gateway.certdir=/etc/opt/SUNWps/cert/portal
gateway.allow.client.caching=true
gateway.userProfile.cacheSize=1024
gateway.userProfile.cacheSleepTime=60000
gateway.userProfile.cacheCleanupTime=300000
gateway.bindipaddress=10.12.147.71
gateway.sockretries=3
gateway.enable.accelerator=false
gateway.enable.customurl=false
gateway.httpurl=http://siroe.india.sun.com
gateway.httpsurl=https://siroe.india.sun.com
gateway.favicon=https://siroe.india.sun.com
gateway.logging.password=ALKJDF123SFLKJJSDFU
表 2-1 は、platform.conf ファイルのすべてのフィールドと、その説明を示しています。表は 3 つの列で構成されています。最初の列はファイル内のエントリを、2 番目の列はデフォルト値がある場合に、そのデフォルト値を、3 番目の列はフィールドの簡単な説明をそれぞれ示します。
ゲートウェイの起動と停止デフォルトでは、ゲートウェイはユーザー noaccess として起動されます。
ゲートウェイを起動するには
- ゲートウェイをインストールし、必要なプロファイルを作成した後、次のコマンドを実行してゲートウェイを起動します。
gateway-install-root/SUNWps/bin/gateway -n default start
default はインストール時に作成されたデフォルトのゲートウェイプロファイルです。独自のプロファイルを後で作成できます。その場合、新しいプロファイルでゲートウェイを再起動します。「ゲートウェイプロファイルの作成」を参照してください。
ゲートウェイのインスタンスが複数ある場合は、次のコマンドを使用します。
gateway-install-root/SUNWps/bin/gateway start
このコマンドにより、指定されたマシン上に設定されているすべてのゲートウェイインスタンスが起動します。
注
サーバー (ゲートウェイのインスタンスを設定したマシン) を再起動する と、ゲートウェイで設定されたすべてのインスタンスが再起動します。
/etc/opt/SUNWps ディレクトリに古いプロファイルまたはバックアップ用 のプロファイルが残っていないことを確認してください。
ゲートウェイを停止するには
ゲートウェイを停止するには、次のコマンドを実行します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name stop
ゲートウェイのインスタンスが複数ある場合は、次のコマンドを使用します。
gateway-install-root/SUNWps/bin/gateway stop
このコマンドにより、指定されたマシンで稼動するすべてのゲートウェイインスタンスが停止します。
ゲートウェイの再起動通常はゲートウェイを再起動する必要はありません。再起動するのは、次のいずれかのイベントが発生した場合です。
別のプロファイルでゲートウェイを再起動するには
ゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n new-gateway-profile-name start
ゲートウェイを再起動するには
端末ウィンドウで root として接続し、次の操作を行います。
ゲートウェイ watchdog を設定するには
watchdog がゲートウェイを監視する間隔を設定することができます。この間隔はデフォルトでは 60 秒に設定されています。これを変更する場合は、 crontab で次の行を編集します。
0-59 * * * * gateway-install-root/SUNWps/bin/rwproxd/bin/checkgw /var/opt/SUNWps/.gw.5 > /dev/null 2>&1
crontab で crontab のエントリを設定する方法については、マニュアルページを参照してください。
Identity Server へアクセスするプロキシの指定ゲートウェイが、Portal Server に配備されている SRA サポート (RemoteConfigServlet) にアクセスするために使用する hostproxy を指定することができます。このプロキシは、Portal Server および Identity Server にアクセスするためにゲートウェイが使用します。
プロキシを指定するには
chroot 環境でのゲートウェイの実行chroot 環境でセキュリティを高めるには、chroot ディレクトリのコンテンツを最小限に抑える必要があります。たとえば、chroot のディレクトリのファイルを修正できるプログラムが存在する場合、chroot はサーバーで chroot ツリーのファイルが攻撃者によって修正されるのを保護しません。CGI プログラムは bourne シェル、C シェル、Korn シェル、または Perl などのインタープリタ型言語では記述できませんが、バイナリにコンパイルする必要があるため、インタープリタが chroot ディレクトリツリーに存在する必要がありません。
chroot をインストールするには
- 端末ウィンドウで root として、次のファイルをネットワーク上のコンピュータ、バックアップテープ、フロッピーディスクなどの外部ソースにコピーします。
cp /etc/vfstab external-device
cp /etc/nsswitch.conf external-device
cp /etc/hosts external-device
- 次の場所から mkchroot スクリプトを実行します。
portal-server-install-root/SUNWps/bin/chroot
注
mkchroot スクリプトの実行が開始すると、Ctrl-C でこのスクリプトを終 了することはできません。
mkchroot スクリプトの実行中にエラーが発生した場合は、「mkchroot ス クリプトの実行の失敗」を参照してください。
別の root ディレクトリ (new_root_directory) が要求されます。スクリプトにより新しいディレクトリが作成されます。
次の例では、new_root_directory は /safedir/chroot です。
- platform.conf ファイル内に記述されている Java ディレクトリを、次のコマンドを使用して chroot ディレクトリに手動でマウントします。
mkdir -p /safedir/chroot/java-dir
mount -F lofs java-dir /safedir/chroot/java-dir
Solaris 9 の場合は次のコマンドを使用します。
mkdir -p /safedir/chroot/usr/lib/32
mount -F lofs /usr/lib/32 /safedir/chroot/usr/lib/32
mkdir -p /safedir/chroot/usr/lib/64
mount -F lofs /usr/lib/64 /safedir/chroot/usr/lib/64
システム起動時にこのディレクトリをマウントするには、/etc/vfstab ファイルに対応するエントリを追加します。
java-dir - /safedir/chroot/java-dir lofs - no -
Solaris 9 の場合は次を追加します。
/usr/lib/32 - /safedir/chroot/usr/lib/32 lofs - no -
/usr/lib/64 - /safedir/chroot/usr/lib/64 lofs - no -
- 次のコマンドを入力して、ゲートウェイを再起動します。
mkchroot スクリプトの実行の失敗
mkchroot スクリプトの実行中にエラーが発生した場合、スクリプトによりファイルは初期状態に復元されます。
次のサンプルでは、/safedir/chroot は chroot ディレクトリです。
次のエラーメッセージが表示される場合、
Not a Clean Exit
- 「chroot をインストールするには」の手順 1 で使用したバックアップファイルを元の場所にコピーし、次のコマンドを実行します。
umount /safedir/chroot/usr/java1.2
umount /safedir/chroot/proc
umount /safedir/chroot/dev/random
- /safedir/chroot ディレクトリを削除します。
chroot 環境でのゲートウェイの再起動ゲートウェイマシンを再起動した場合、次の手順を実行して chroot 環境でゲートウェイを再起動します。
chroot 環境でゲートウェイを再起動するには
ゲートウェイの複数インスタンスの作成gwmultiinstance スクリプトを使用して、ゲートウェイの新しいインスタンスを作成します。できるだけ、ゲートウェイプロファイルを作成してからこのスクリプトを実行してください。
- root としてログインし、次のディレクトリに移動します。
gateway-install-root/SUNWps/bin/
- 次の複数インスタンススクリプトを実行します。
./gwmultiinstance
- 次のいずれかのインストールオプションを選択します。
1) Create a new gateway instance
2) Remove a gateway instance
3) Remove all gateway instances
4) Exit
1 を選択した場合は、次の質問に答えます。
What is the name of the new gateway instance?
What protocol will the new gateway instance use? [https]
What port will the new gateway instance listen on?
What is the fully qualified hostname of the portal server?
What port should be used to access the portal server?
What protocol should be used to access the portal server? [http]
What is the portal server deploy URI?
What is the organization DN? [dc=iportal,dc=com]
What is the identity server URI? [/amserver]
What is the identity server password encryption key?
Please provide the following information needed for creating a self-signed certificate:
What is the name of your organization?
What is the name of your division?
What is the name of your city or locality?
What is the name of your state or province?
What is the two-letter country code?
What is the password for the Certificate Database? Again?
What is the password for the logging user? Again?
Have you created the new gateway profile in the admin console? [y]/n
Start the gateway after installation? [y]/n
- 新規ゲートウェイプロファイル名でゲートウェイの新規インスタンスを起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
gateway-profile-name は、ゲートウェイの新規インスタンスです。
Web プロキシの使用サードパーティ製の Web プロキシを使用して HTTP リソースにアクセスするように、ゲートウェイを設定することができます。Web プロキシには、クライアントとインターネットの間に設置されます。
Web プロキシの設定
ドメインおよびサブドメインごとに異なるプロキシを使用できます。これらのエントリから、特定のドメインの特定のサブドメインへのアクセスに使用するプロキシがゲートウェイに伝えられます。ゲートウェイで指定したプロキシ設定は次のように機能します。
ドメインとサブドメインのプロキシの設定については、「ドメインとサブドメインのプロキシのリストの作成」を参照してください。
「プロキシを使用する」オプションの設定については、「Web プロキシ使用の有効化」を参照してください。
図 2-1 は、ゲートウェイサービスのプロキシ設定に基づいてプロキシ情報が解決される手順を示しています。
図 2-1 Web プロキシの管理
図 2-1 では、「プロキシを使用する」が選択され、「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 を使用する必要があることを表します。
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
ゲートウェイは、表 2-2 に示されるテーブルでこれらのエントリを内部的にマッピングします。
表 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つある場合、プロ キシ情報を持つエントリが有効なエントリと見なされ、 もう一つは無視される。
15
host9.sesta.com
p11
リストで指定されたプロキシ
16
siroe.com
直接
siroe.com にプロキシが指定されていないため、直接接 続が試行される
17
host12.siroe.com
p12
リストで指定されたプロキシ
18
host13.siroe.com
p13
リストで指定されたプロキシ
19
host14.siroe.com
直接
siroe.com または host14 に対してプロキシが指定され ていないため、直接接続が試行される
20
*.siroe.com
p14
エントリ 23 の説明を参照
21
host15.siroe.com
p15
リストで指定されたプロキシ
22
host16.siroe.com
直接
siroe.com の host16 に対してプロキシが指定されてい ないため、直接接続が試行される
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 をリライトします。
警告
「ドメインとサブドメインのプロキシ」リストのエントリ * は、リライトの 対象と見なされません。たとえば、表 2-2 の例では、エントリ 24 はリライ トの対象になりません。
リライタについては、第 3 章「リライタ」を参照してください。
デフォルトのドメインとサブドメイン
URL の最終ホストが完全修飾名になっていない場合、完全修飾名に到達するためにデフォルトのドメインおよびサブドメインが使用されます。
管理コンソールの「デフォルトのドメインサブドメイン」フィールドに、次のエントリが設定されていると仮定します。
red.sesta.com
上記の例では、sesta.com がデフォルトのドメイン、デフォルトのサブドメインは red です。
URL、host1 が要求された場合、これはデフォルトのドメインとサブドメインを使用して host1.red.sesta.com として解決されます。「ドメインとサブドメインのプロキシ」リストで host1.red.sesta.com が検索されます。
プロキシ自動設定の使用「ドメインとサブドメインのプロキシ」リストの情報を無視するには、プロキシ自動設定 (Proxy Auto Configuration、PAC) 機能を有効にします。PAC の設定については、「プロキシ自動設定 (PAC) サポートの有効化」を参照してください。
PAC ファイルを使用するときは、次の点に注意してください。
- ゲートウェイマシンの $JRE_HOME/lib/ext ディレクトリに js.jar が存在する必要があります。このファイルが存在しない場合、ゲートウェイは PAC ファイルを解析できません。
- ゲートウェイは起動時に、ゲートウェイプロファイルの「PAC ファイルの場所」に指定されている場所から PAC ファイルをフェッチします。場所の設定については、「PAC ファイルの場所の指定」を参照してください。
- ゲートウェイは、URLConnection API を使用してこの場所にアクセスします。PAC ファイルの場所にアクセスするようにプロキシを設定しなければならないときは、プロキシを次のように設定します。
- PAC ファイルの初期化に失敗した場合は、ゲートウェイは「ドメインとサブドメインのプロキシ」リストの情報を使用します。
- PAC ファイルから空白文字列または「NULL」が返される場合、ゲートウェイはそのホストがイントラネットに属していないと判断します。これは、「ドメインとサブドメインのプロキシ」に含まれないホストの扱いと似ています。
ホストへのアクセスに直接接続を使用する場合、ゲートウェイは「DIRECT」を返します。「DIRECT または NULL のいずれかが返される例」を参照してください。
- 複数のプロキシが指定されている場合、ゲートウェイは最初に返されるプロキシだけを使用します。ホストに指定されている複数のプロキシの間で、フェイルオーバやロードバランスは行われません。
- ゲートウェイは SOCKS プロキシを無視して直接接続を試み、ホストがイントラネットの一部であると解釈します。
- イントラネットの一部に含まれないホストへのアクセスに使用するプロキシを指定するには、「STARPROXY」というプロキシタイプを使用します。これは、PAC 形式のファイル拡張子で、ゲートウェイプロファイルの「ドメインとサブドメインのプロキシ」セクションに指定される * proxyHost:port エントリと似ています。「STARPROXY が返される例」を参照してください。
サンプル PAC ファイルの使用
次の例は、「ドメインとサブドメインのプロキシ」リストに含まれる URL と、それに対応する PAC ファイルを示しています。
DIRECT または NULL のいずれかが返される例
次の「ドメインとサブドメインのプロキシ」を使用する場合、
intranet1.com
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 が返される例
次の「ドメインとサブドメインのプロキシ」を使用する場合、
対応する 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 domain 内のホストに対するものであれば、ゲートウェイは proxy.intranet1.com:8080 にアクセスします。proxy.intranet1.com:8080 が停止している場合は、要求は失敗します。ゲートウェイは、ファイルオーバを行わず、proxy1.intranet1.com:8080 にはアクセスしません。
Netlet プロキシの使用Netlet パケットはゲートウェイで解読され、宛先サーバーに送られます。ただし、ゲートウェイはすべての Netlet ターゲットにアクセスする場合、非武装ゾーン (DMZ) とイントラネット間のファイアウォールを経由する必要があります。これにはファイアウォールで多くのポートを開かなければなりません。Netlet プロキシを使用することで、プロキシで開かれるポートの数を最小化することができます。
Netlet プロキシは、クライアントからの安全なトンネルをゲートウェイを経由してイントラネット内の Netlet プロキシまで拡張することで、ゲートウェイとイントラネット間のセキュリティを補強します。プロキシを使用すると、Netlet パケットが Netlet プロキシにより解読され、送信先に送られます。
Netlet プロキシは、次のような点で便利です。
- セキュリティのレイヤーを補強します。
- 配備サイズが大きな環境で、ゲートウェイから内部ファイアウォールに必要以上の IP アドレスおよびポートを使用しないようにします。
- ゲートウェイと Portal Server 間で開かれるポートの数を 1 に制限します。このポート番号はインストール時に設定できます。
- 図 2-2 の「Netlet プロキシをインストールした場合」に示すように、クライアントとゲートウェイ間の安全なチャネルを Portal Server まで延長します。Netlet プロキシはデータの暗号化によってセキュリティを改善しますが、システムリソースの使用を増やす場合があります。Netlet プロキシのインストールについては、『Sun Java Enterprise System インストールガイド』を参照してください。
次の処理を実行できます。
- Portal Server ノードまたは別のノードで Netlet プロキシのインストールを選択します。
- 複数の Netlet プロキシをインストールし、それらを管理コンソールで単一のゲートウェイに対して設定します。これはロードバランスに役立ちます。詳細については、「Netlet プロキシリストの有効化と作成」を参照してください。
- 単一のマシンで Netlet プロキシの複数のインスタンスを設定します。
- ゲートウェイの複数のインスタンスに対して、Netlet プロキシの単一のインストールを設定します。
- Web プロキシ経由のトンネル Netlet。この設定については、「Web プロキシ経由のトンネル Netlet の有効化」を参照してください。
図 2-2 は、Netlet プロキシをインストールした場合とインストールしない場合のゲートウェイと Portal Server の 3 つの実装例を示しています。クライアント、2 つのファイアウォール、2 つのファイアウォールの間にあるゲートウェイ、Portal Server、および Netlet ターゲットサーバーから構成されます。
最初の例では、Netlet プロキシをインストールしていないゲートウェイと Portal Server を示しています。ここでは、クライアントからゲートウェイの間だけでデータの暗号化が行われます。Netlet 接続の要求があるたびに、2 番目のファイアウォールでポートが開かれます。
2 番目の例では、ゲートウェイと、Netlet プロキシがインストールされている Portal Server を示しています。この場合、データの暗号化はクライアントから Portal Server までのすべての区間に拡張されています。すべての Netlet が Netlet プロキシを通じてルーティングされているため、Netlet 要求に対して 2 番目のファイアウォールで開く必要があるのは 1 ポートのみです。
3 番目の例では、Netlet プロキシが別のノードにインストールされている Portal Server とゲートウェイを示しています。別のノードに Netlet プロキシをインストールすると、Portal Server ノードの負荷が減少します。ここでも、2 番目のファイアウォールで開く必要があるのは 2 ポートのみです。一つのポートは Portal Server への要求を処理し、もう一つのポートは Netlet の要求を Netlet プロキシサーバーにルーティングします。
図 2-2 Netlet プロキシの実装
Netlet プロキシのインスタンスの作成
Netlet プロキシの新しいインスタンスを Portal Server ノードまたは別のノードに作成するときは、nlpmultiinstance スクリプトを使用します。できるだけ、ゲートウェイプロファイルを作成してからこのスクリプトを実行してください。
- root としてログインし、次のディレクトリに移動します。
netlet-install-dir/SUNWps/bin
- 次の複数インスタンススクリプトを実行します。
./nlpmultiinstance
- nlpmultiinstance スクリプトが表示する質問に答えます。
- What is the name of the new netlet proxy instance?
- このノードに同じ名前でリライタプロキシインスタンスが設定されている場合は、この Netlet プロキシインスタンスで同じ設定を使用するかどうかの確認が求められます。
- yes を指定した場合は、次の 2 つの質問に答えます。
- no を指定した場合は、次の質問に答えます。
- What protocol will the new netlet proxy instance use?
- What port will the new netlet proxy instance listen on?
- What is the name of your organization?
- What is the name of your division?
- What is the name of your city or locality?
- What is the name of your state or province?
- What is the two-letter country code?
- What is the password for the certificate Database?
- What is the password for the logging user?
- Have you created the new netlet proxy profile in the admin console?
- If you answered yes, start the netlet proxy after installation?
- 適切なゲートウェイプロファイル名で Netlet プロキシの新規インスタンスを起動します。
netlet-proxy-install-root/SUNWps/bin/netletd -n gateway-profile-name start
ここで gateway-profile-name は必要なゲートウェイインスタンスのプロファイル名です。
Netlet プロキシの有効化
Netlet プロキシを有効化するときは、Identity Server 管理コンソールの「SRA 設定」の下にある「ゲートウェイ」サービスを使用します。「Netlet プロキシリストの有効化と作成」を参照してください。
Netlet プロキシの再起動
プロキシが何らかの理由で強制終了した場合に再起動するように、Netlet プロキシを設定することができます。Netlet プロキシを監視し、Netlet プロキシが停止したときに再起動するように watchdog プロセスをスケジューリングできます。
Netlet プロキシは手動で再起動することもできます。
Netlet プロキシを再起動するには
端末ウィンドウで root として接続し、次の操作を行います。
- 次の方法で watchdog プロセスを開始します。
netlet-proxy-install-root/SUNWps/bin/netletd watchdog on
crontab にエントリが作成され、watchdog プロセスが有効になります。watchdog は Netlet プロキシポートを監視し、ポートが停止した場合にプロキシを再起動します。
- 次の方法で、Netlet プロキシを手動で起動します。
netlet-proxy-install-root/SUNWps/bin/netletd -n gateway-profile-name start
ここで gateway-profile-name は必要なゲートウェイインスタンスのプロファイル名です。
Netlet プロキシの watchdog を設定するには
watchdog が Netlet プロキシの状態を監視する間隔を設定することができます。この間隔はデフォルトでは 60 秒に設定されています。これを変更する場合は、crontab で次の行を編集します。
0-59 * * * * netlet-install-dir/bin/checkgw /var/opt/SUNWps/.gw 5 > /dev/null 2>&1
リライタプロキシの使用リライタプロキシは、イントラネット上にインストールされます。ゲートウェイは、コンテンツを直接取得せずにすべての要求をリライタプロキシに送信し、リライタプロキシはコンテンツをフェッチしてゲートウェイに返します。
リライタプロキシを使用する利点は 2 つあります。
リライタプロキシを指定しない場合、いずれかのイントラネットコンピュータにアクセスしようとすると、ゲートウェイコンポーネントによりイントラネットコンピュータに直接つながります。
リライタプロキシの有効化については、「リライタプロキシリストの有効化と作成」を参照してください。
リライタプロキシのインスタンスの作成
リライタプロキシの新しいインスタンスを Portal Server ノードに作成するときは、rwpmultiinstance スクリプトを使用します。できるだけ、ゲートウェイプロファイルを作成してからこのスクリプトを実行してください。
- root としてログインし、次のディレクトリに移動します。
rewriter-proxy-install-root/SUNWps/bin
- 次の複数インスタンスのスクリプトを実行します。
./rwpmultiinstance
- スクリプトが表示する質問に答えます。
- What is the name of the new rewriter proxy instance?
- このノードに同じ名前でリライタプロキシインスタンスが設定されている場合は、このリライタプロキシインスタンスで同じ設定を使用するかどうかの確認が求められます。
- yes を指定した場合は、次の 2 つの質問に答えます。
- no を指定した場合は、次の質問に答えます。
- What protocol will the new rewriter proxy instance use?
- What port will the new rewriter proxy instance listen on?
- What is the name of your organization?
- What is the name of your division?
- What is the name of your city or locality?
- What is the name of your state or province?
- What is the two-letter country code?
- What is the password for the certificate Database?
- What is the password for the logging user?
- Have you created the new rewriter proxy profile in the admin console?
- If you answered yes, start the rewriter proxy after installation?
- 適切なゲートウェイプロファイル名でリライタプロキシの新規インスタンスを起動します。
rewriter-proxy-install-root/SUNWps/bin/rwproxyd -n gateway-profile-name start
ここで gateway-profile-name は必要なゲートウェイインスタンスのプロファイル名です。
リライタプロキシの有効化
リライタプロキシを有効化するときは、Identity Server 管理コンソールの「SRA 設定」の下にある「ゲートウェイ」サービスを使用します。「リライタプロキシリストの有効化と作成」を参照してください。
リライタプロキシの再起動
プロキシが何らかの理由で強制終了した場合に再起動するように、リライタプロキシを設定することができます。リライタプロキシを監視し、リライタプロキシが停止したときに再起動するように watchdog プロセスをスケジューリングできます。
リライタプロキシは手動で再起動することもできます。
リライタプロキシを再起動するには
端末ウィンドウで root として接続し、次の操作を行います。
- 次の方法で watchdog プロセスを開始します。
rewriter-proxy-install-root/SUNWps/bin/rwproxd watchdog on
crontab にエントリが作成され、watchdog プロセスが有効になります。watchdog はリライタプロキシポートを監視し、ポートが停止した場合にプロキシを再起動します。
- 次の方法で、リライタプロキシを手動で起動します。
rewriter-proxy-install-root/SUNWps/bin/rwproxd -n gateway-profile-name start
ここで gateway-profile-name は必要なゲートウェイインスタンスのプロファイル名です。
リライタプロキシの watchdog を設定するには
watchdog がリライタプロキシを監視する間隔を設定することができます。この間隔はデフォルトでは 60 秒に設定されています。これを変更する場合は、crontab で次の行を編集します。
0-59 * * * * rewriter-proxy-install-root/bin/checkgw /var/opt/SUNWps/.gw 5 > /dev/null 2>&1
ゲートウェイでの逆プロキシの使用プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。特定の逆プロキシの配備は、インターネットのコンテンツの配信や、ロードバランス、およびキャッシングのために設定されます。
ゲートウェイの前にサードパーティの逆プロキシがある配備の場合、応答は、ゲートウェイの URL ではなく逆プロキシの URL でリライトされる必要があります。このためには、次のように設定します。
逆プロキシを有効化するには
- root としてログインし、目的のゲートウェイインスタンスの platform.conf ファイルを編集します。
/etc/opt/SUNWps/platform.conf.gateway-profile-name
- 次のエントリを追加します。
gateway.virtualhost=fully-qualified-gateway-host gateway-ip-address fully- qualified-reverse-proxyhost
gateway.enable.customurl=true (この値はデフォルトでは、false に設定されています。)
gateway.httpurl=http reverse-proxy-URL
gateway.httpsurl=https reverse-proxy-URL
gateway.httpurl は、ゲートウェイプロファイルに HTTP ポートとしてリストされているポートで受信される要求への応答をリライトするために使用されます。
gateway.httpsurl は、ゲートウェイプロファイルに HTTPS ポートとしてリストされているポートで受信される要求への応答をリライトするために使用されます。
- ゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
これらの値を指定しない場合、ゲートウェイは通常どおりに動作します。
クライアント情報の取得ゲートウェイがいずれかの内部サーバーにクライアント要求を転送するときに、HTTP 要求に HTTP ヘッダーが追加されます。3 つのヘッダーを使用して追加のクライアント情報を取得し、ゲートウェイの存在を検出することができます。
HTTP 要求ヘッダーを表示するには、platform.conf ファイル内のエントリを gateway.error=message に設定し、サーブレット API から request.getHeader() を使用します。
最初の列はヘッダーのラベル、2 番目の列はそのヘッダーの構文、3 番目の列はヘッダーラベルの説明を示しています。
表 2-3 HTTP ヘッダー内の情報
ヘッダー
構文
説明
PS-GW-PDC
PS-GW-PDC: true/false
ゲートウェイに PDC が有効であるかどうかを示す
PS-Netlet
PS-Netlet:enabled=true/false
ゲートウェイで Netlet が有効化または無効化されて いることを示す
有効化されている場合は、暗号化オプションが挿入 され、ゲートウェイが HTTPS モード (encryption=ssl) または HTTP モード (encryption=plain) のどちらで実行されているかが示 される
例
PS-Netlet: enabled=false
Netlet は無効化されています。
PS-Netlet: enabled=true; encryption=ssl
Netlet は有効で、ゲートウェイは SSL モードで稼動 している
Netlet が有効でない場合は、encryption=ssl/plain は 挿入されない
PS-GW-URL
PS-GW-URL: http(s)://gatewayURL(:port)
クライアントが接続している URL を示す
標準ポート以外の場合 (つまり、80/443 以外のポー トでゲートウェイが HTTP/HTTPS モードで稼動し ている場合) は、「:port」が挿入される
PS-GW-Rewriting -URL
PS-GW-URL: http(s)://gatewayURL(:port) /[SessionInfo]
ゲートウェイがすべてのページをリライトする URL を示す
1. ブラウザが cookie をサポートする場合、この ヘッダーの値は PS-GW-URL ヘッダーと同じに なる
2. ブラウザが cookie をサポートしない場合は、
注 : 応答の一部で、ユーザーの Identity Server の セッション ID が変更された場合 (認証ページからの 応答など)、ページは、それまでヘッダーに指定され ていた値ではなく、その値で書き換えられる
例
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCusto mEncodedValue/
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/$SessionID
PS-GW-CLientIP
PS-GW-CLientIP: IP
ゲートウェイが recievedSocket.getInetAddress().getHostAddress() から取得した IP
クライアントがゲートウェイに直接接続する場合、 これによって IP が特定される
注 : JSS/NSS のバグにより、現在は表示されない
認証連鎖の使用認証連鎖することにより、通常の認証メカニズムを超えた高いレベルのセキュリティがもたらされます。ユーザーを複数の認証メカニズムで認証することができます。
ここでは、PDC 認証によってゲートウェイで認証連鎖を有効化する手順だけを説明します。PDC 認証を使用しない場合のゲートウェイでの認証連鎖については、『Sun ONE Identity Server 管理ガイド』を参照してください。
たとえば、PDC、Unix、Radius 認証モジュールを連鎖させると、ユーザーは Portal Server デスクトップにアクセスするために 3 つのモジュールすべてについて認証が必要になります。
既存の PDC インスタンスに認証モジュールを追加するには
- Identity Server 管理コンソールに管理者としてログインします。
- 適切な組織を選択します。
- 「表示」ドロップダウンメニューから「サービス」を選択します。
左のパネルにサービスが表示されます。
- 「認証設定」の隣の矢印をクリックします。
「サービスインスタンスリスト」が表示されます。
- gatewaypdc をクリックします。
「gatewaypdf プロパティを表示」ページが表示されます。
- 「認証設定」の「編集」のリンクをクリックします。
「モジュールの追加」が表示されます。
- 「モジュール名」を選択し、「フラグ」を「Required」に設定します。オプションは空白のまま残せます。
- 「了解」をクリックします。
- 1 つまたは複数のモジュールを追加したら、「保存」をクリックします。
- 「gatewaypdc プロパティの表示」ページをクリックします。
- 変更を有効にするために、ゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
ワイルドカード証明書の使用ワイルドカード証明書は、ホストの完全修飾 DNS 名にワイルドカード文字を含む単一の証明書を受け付けます。
これによって、同じドメイン内で証明書が複数のホストを保証することが可能になります。たとえば、*.domain.com の証明書は abc.domain.com と abc1.domain.com に使用できます。実際には、この証明書は domain.com ドメイン内のすべてのホストに有効です。
完全修飾ホスト名で * を指定する必要があります。たとえば、完全修飾ホスト名が abc.florizon.com の場合、*.florizon.com のように指定します。生成される証明書は、今度は florizon.com ドメインのすべてのホスト名に有効になります。
ブラウザキャッシングの無効化ゲートウェイコンポーネントは Web ブラウザのみを使用して任意の場所からバックエンド企業データへの安全なアクセスを提供します。そのため、クライアントが情報をローカルにキャッシュする必要がない場合があります。
ゲートウェイを通じてリダイレクトされるページのキャッシングを無効にするには、そのゲートウェイの platform.conf ファイルの属性を修正します。
このオプションを無効にすると、ゲートウェイのパフォーマンスに影響する場合があります。ポータルデスクトップが再表示されるたびに、ブラウザがすでにキャッシュしているイメージを含めページが参照するすべてのデータをゲートウェイで取り出す必要があるためです。ただし、この機能を有効にしても、リモートアクセスされた安全なコンテンツの足跡は、クライアントサイトでキャッシュとして残りません。これがパフォーマンスへの影響よりも重要な意味を持つのは、企業 IT の制御下にないインターネットカフェやその類のリモートロケーションから企業ネットワークにアクセスしている場合です。
ブラウザキャッシングを無効にする手順
- root としてログインし、目的のゲートウェイインスタンスの platform.conf ファイルを編集します。
/etc/opt/SUNWps/platform.conf.gateway-profile-name
- 次の行を編集します。
gateway.allow.client.caching=true
この値はデフォルトでは、true に設定されています。この値を false に変更するとクライアントサイドでのブラウザキャッシングが無効になります。
- ゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
ゲートウェイサービスのユーザーインタフェースのカスタマイズここでは、編集可能な各種のプロパティファイルについて説明します。管理コンソールのゲートウェイサービスのラベル、エラーメッセージ、ログ情報を編集できます。これはさまざまなロケールの製品をカスタマイズする場合に便利です。
次のファイルをカスタマイズできます。
portal-server-install-root/SUNWam/locale/srapGatewayAdminConsole.properties
portal-server-installl-dir/SUNWps/locale/srapGateway.properties
portal-server-install-root/SUNWps/web-src/WEB-INF/classes/srapgwadminmsg.prop erties
srapGatewayAdminConsole.properties ファイル
このファイルを編集して、管理コンソールでゲートウェイサービスに表示されるファイル名を変更します。
srapGateway.properties ファイル
このファイルを次のように編集します。
srapgwadminmsg.properties ファイル
このファイルを次のように編集します。
連携管理の使用連携管理により、ユーザーが 1 つのネットワーク ID を持つように、ユーザーはユーザーのローカル ID を収集できます。連携管理ではネットワーク ID を使用して、ユーザーによる 1 つのサービスプロバイダサイトへのログインを許可し、ID を再認証することなく、他のサービスプロバイダサイトへのアクセスを許可します。これをシングルサインオンと呼びます。
Portal Server では、連携管理をオープンモードとセキュアモードに設定できます。連携管理をオープンモードに設定する方法については、『Sun ONE Portal Server 管理者ガイド』を参照してください。Secure Remote Access を使用して連携管理を設定する前に、これがオープンモードで機能することを確認します。ユーザーが同じブラウザで連携管理をオープンモードとセキュアモードの両方で使用できるようにするには、ブラウザから cookie とキャッシュをクリアする必要があります。
連携管理の詳細については、『Sun ONE Identity Server Customization and API Guide』を参照してください。
連携管理の例
ユーザーは、最初のサービスプロバイダに対して認証を行います。サービスプロバイダは、Web ベースのサービスを提供する営利、または非営利の組織です。この広範な分類には、インターネットポータル、小売、運輸、金融、エンターテイメント、図書館、大学、政府などの機関が含まれます。
サービスプロバイダは、cookie を使用してユーザーのセッション情報をクライアントブラウザに格納します。また、cookie にはユーザーの ID プロバイダも含まれます。
ID プロバイダは、認証サービスの提供に特化したサービスプロバイダです。認証の管理サービスとして、識別情報を維持、管理します。ID プロバイダが行う認証は、そのプロバイダと関連するすべてのサービスプロバイダで尊重されます。
ユーザーが、ID プロバイダと関連しないサービスにアクセスしようとすると、ID プロバイダはそのサービスプロバイダに cookie を転送します。次に、このサービスプロバイダは、cookie 内で呼び出される ID プロバイダにアクセスします。
ただし、異なる DNS ドメインの間で cookie を読み取ることはできません。このため、サービスプロバイダを適切な ID プロバイダにリダイレクトし、そのユーザーのシングルサインオンを実現するために、共通ドメイン cookie サービスが使用されます。
連携管理リソースの設定
連携リソース (サービスプロバイダ、ID プロバイダ、共通ドメイン cookie サービス (Common Domain Cookie Service、CDCS)) は、それぞれが常駐するゲートウェイプロファイルベースで設定されます。ここでは、次の 3 つの例の設定方法について説明します。
設定 1
この設定では、サービスプロバイダ、ID プロバイダ、共通ドメイン cookie サービス (CDCS) が同一の企業イントラネットに配備され、ID プロバイダはインターネット DNS (Domain Name Server) に公開されていません。CDCS の使用はオプションです。
この設定では、ゲートウェイは Portal Server であるサービスプロバイダをポイントします。この設定は、Portal Server の複数のインスタンスで有効です。
- Identity Server 管理コンソールに管理者としてログインします。
- 管理コンソールの「サービス設定」タブを選択します。
- 「SRA 設定」の「ゲートウェイ」の隣の矢印をクリックします。
「ゲートウェイ」ページが表示されます。
- 編集する属性が含まれるゲートウェイプロファイルの隣の「編集」をクリックします。
「ゲートウェイプロファイルを編集」ページが表示されます。
- 「コア」タブをクリックします。
- 「Cookie 管理を有効」チェックボックスにチェックマークを付けて、cookie 管理を有効化します。
- 「Portal Server のリスト」フィールドまでスクロールし、「非認証 URL」リストに含まれる /amserver や /portal/dt などの相対 URL を使用できるように Portal Server 名を入力します。
例http://idp-host:port/amserver/js
http://idp-host:port/amserver/UI/Login
http://idp-host:port/amserver/css
http://idp-host:port/amserver/SingleSignOnService
http://idp-host:port/amserver/UI/blank
http://idp-host:port/amserver/postLogin
http://idp-host:port/amserver/login_images
- 「Portal Server のリスト」フィールドまでスクロールし、Portal Server 名を入力します。たとえば、/amserver と入力します。
- 「保存」をクリックします。
- 「セキュリティ」タブをクリックします。
- 「非認証 URL」リストまでスクロールし、連携リソースを追加します。
例/amserver/config/federation
/amserver/IntersiteTransferService
/amserver/AssertionConsumerservice
/amserver/fed_images
/amserver/preLogin
/portal/dt
- 「追加」をクリックします。
- 「保存」をクリックします。
- 「非認証 URL」リストに含まれる URL への到達にプロキシが必要な場合は、「プロキシ」タブをクリックします。
- 「ドメインとサブドメインのプロキシ」フィールドまでスクロールし、適切な Web プロキシを入力します。
- 「追加」をクリックします。
- 「保存」をクリックします。
- 端末ウィンドウから、次のコマンドを指定してゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
設定 2
この設定では、ID プロバイダと共通ドメイン cookie プロバイダ (CDCP) は企業イントラネットに配備されていません。または、ID プロバイダがインターネット上のサードパーティプロバイダとして存在します。
この設定では、ゲートウェイは Portal Server であるサービスプロバイダをポイントします。この設定は、Portal Server の複数のインスタンスで有効です。
- Identity Server 管理コンソールに管理者としてログインします。
- 管理コンソールの「サービス設定」タブを選択します。
- 「SRA 設定」の「ゲートウェイ」の隣の矢印をクリックします。
「ゲートウェイ」ページが表示されます。
- 編集する属性が含まれるゲートウェイプロファイルの隣の「編集」をクリックします。
「ゲートウェイプロファイルを編集」ページが表示されます。
- 「コア」タブをクリックします。
- 「Cookie 管理を有効」チェックボックスにチェックマークを付けて、cookie 管理を有効化します。
- 「Portal Server のリスト」フィールドをスクロールし、「非認証 URL」リストに含まれる /amserver や /portal/dt などの相対 URL を使用できるようにサービスプロバイダの Portal Server 名を入力します。
http://idp-host:port/amserver/js
http://idp-host:port/amserver/UI/Login
http://idp-host:port/amserver/css
http://idp-host:port/amserver/SingleSignOnService
http://idp-host:port/amserver/UI/blank
http://idp-host:port/amserver/postLogin
http://idp-host:port/amserver/login_images
- 「保存」をクリックします。
- 「セキュリティ」タブをクリックします。
- 「非認証 URL」リストまでスクロールし、連携リソースを追加します。
例/amserver/config/federation
/amserver/IntersiteTransferService
/amserver/AssertionConsumerservice
/amserver/fed_images
/amserver/preLogin
/portal/dt
- 「追加」をクリックします。
- 「保存」をクリックします。
- 「非認証 URL」リストに含まれる URL への到達にプロキシが必要な場合は、「プロキシ」タブをクリックします。
- 「ドメインとサブドメインのプロキシ」フィールドまでスクロールし、適切な Web プロキシを入力します。
- 「追加」をクリックします。
- 「保存」をクリックします。
- 端末ウィンドウから、次のコマンドを指定してゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
設定 3
この設定では、ID プロバイダと共通ドメイン cookie プロバイダ (CDCP) は企業イントラネットに配備されていません。または、サービスプロバイダがインターネット上のサードパーティプロバイダとして存在し、ID プロバイダはゲートウェイによって保護されています。
この設定では、ゲートウェイは Portal Server である ID プロバイダをポイントします。
この設定は、Portal Server の複数のインスタンスで有効です。インターネット上でこのような設定が行われることは、あまり多くありません。しかし、一部の企業ネットワークでは、イントラネット内でこのような設定を行っています。この設定では、ID プロバイダはファイアウォールによって保護されたサブネットに常駐し、サービスプロバイダには企業ネットワーク内から直接アクセスできます。
- Identity Server 管理コンソールに管理者としてログインします。
- 管理コンソールの「サービス設定」タブを選択します。
- 「SRA 設定」の「ゲートウェイ」の隣の矢印をクリックします。
「ゲートウェイ」ページが表示されます。
- 編集する属性が含まれるゲートウェイプロファイルの隣の「編集」をクリックします。
「ゲートウェイプロファイルを編集」ページが表示されます。
- 「コア」タブをクリックします。
- 「Cookie 管理を有効」チェックボックスにチェックマークを付けて、cookie 管理を有効化します。
- 「Portal Server のリスト」フィールドをスクロールし、「非認証 URL」リストに含まれる /amserver や /portal/dt などの相対 URL を使用できるように ID プロバイダの Portal Server 名を入力します。
http://idp-host:port/amserver/js
http://idp-host:port/amserver/UI/Login
http://idp-host:port/amserver/css
http://idp-host:port/amserver/SingleSignOnService
http://idp-host:port/amserver/UI/blank
http://idp-host:port/amserver/postLogin
http://idp-host:port/amserver/login_images
- 「保存」をクリックします。
- 「セキュリティ」タブをクリックします。
- 「非認証 URL」リストまでスクロールし、連携リソースを追加します。
例/amserver/config/federation
/amserver/IntersiteTransferService
/amserver/AssertionConsumerservice
/amserver/fed_images
/amserver/preLogin
/portal/dt
- 「追加」をクリックします。
- 「保存」をクリックします。
- 「非認証 URL」リストに含まれる URL への到達にプロキシが必要な場合は、「プロキシ」タブをクリックします。
- 「ドメインとサブドメインのプロキシ」フィールドまでスクロールし、適切な Web プロキシを入力します。
- 「追加」をクリックします。
- 「保存」をクリックします。
- 端末ウィンドウから、次のコマンドを指定してゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
