|
| |
| Sun Java System Portal Server Secure Remote Access 6 2005Q4 管理ガイド | |
第 2 章
ゲートウェイこの章では、ゲートウェイのスムースな実行に必要な、ゲートウェイに関連する概念と情報について説明します。ゲートウェイの設定については、第 9 章「ゲートウェイの設定」を参照してください。
この章で説明する内容は次のとおりです。
ゲートウェイの概要ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。ゲートウェイはリモートユーザーとの単一のインタフェースを通じて、内部 Web サーバーとアプリケーションサーバーのコンテンツを安全に提供します。
各ゲートウェイに対して、次のことを実行する必要があります。
- ゲートウェイプロファイルを作成します。「ゲートウェイプロファイルの作成」を参照してください。
- ゲートウェイのインスタンスを作成します。「ゲートウェイのインスタンスの作成」を参照してください。
- ゲートウェイを設定します。第 9 章「ゲートウェイの設定」を参照してください。
ゲートウェイプロファイルの作成ゲートウェイプロファイルには、ゲートウェイが待機するポート、SSL オプション、およびプロキシオプションなどのゲートウェイの設定に関連したすべての情報が収められています。
ゲートウェイをインストールする場合、デフォルトの値を選択すると「default」という名前のデフォルトゲートウェイプロファイルが作成されます。デフォルトプロファイルに相当する設定ファイルは、次の場所にあります。
/etc/opt/SUNWps/platform.conf.default
/etc/opt/SUNWps は、すべての platform.conf.* ファイルが格納されるデフォルトの場所です。
platform.conf ファイルの内容についての詳細は、「platform.conf ファイルの概要」を参照してください。
次の処理を実行できます。
ゲートウェイプロファイルを作成するには
- Sun JavaTM System Access Manager 管理コンソールに管理者としてログインします。
- 「サービス設定」タブを選択します。
- 「SRA 設定」の「ゲートウェイ」の隣の矢印をクリックします。
右の区画に「ゲートウェイ」ページが表示されます。
- 「新規」をクリックします。
「新規ゲートウェイプロファイルを作成」ページが表示されます。
- 新規ゲートウェイプロファイルの名前を入力します。
- ドロップダウンリストから、新規プロファイルの作成に使用するプロファイルを選択します。
デフォルトでは、新規プロファイルはパッケージ内の「default」プロファイルに基づいて作成されます。カスタムプロファイルを作成している場合、ドロップダウンリストからそのプロファイルを選択できます。新しいプロファイルは、選択したプロファイルのすべての属性を継承します。
新規プロファイル用にコピーした既存のプロファイルは、同じポートをコピーします。このため、既存のプロファイルと競合しないように、新規プロファイルのポートを変更する必要があります。
- 「作成」をクリックします。
新規プロファイルが作成され、「ゲートウェイ」ページに戻ります。このページには、新しいプロファイルが表示されます。
- gwmultiinstance スクリプトを実行して、ゲートウェイのインスタンスを作成します。「ゲートウェイの起動と停止」を参照してください。
- 変更を有効にするには、このゲートウェイプロファイル名でゲートウェイを再起動します。
gateway-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
portal.server.instance=
gateway.cdm.cacheSleepTime=60000
gateway.cdm.cacheCleanUpTime=300000
netletproxy.port=10555
rewriterproxy.port=10556
表 2-1 は、platform.conf ファイルのすべてのフィールドと、その説明を示しています。
ゲートウェイのインスタンスの作成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 Access Manager URI? [/amserver]
What is the Access Manager 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 は、ゲートウェイの新規インスタンスです。
ゲートウェイプロファイル以外に、AMConfig-.instance-name.properties ファイルが /etc/opt/SUNWam/config ディレクトリに作成されます。
portal.server.instance プロパティーが platform.conf ファイルに存在する場合は、対応する AMConfig-instance-name.properties ファイルがゲートウェイによって読み込まれます。portal.server.instance プロパティーが platform.conf ファイルに存在しない場合は、デフォルトの AMConfig ファイル (AMConfig.properties) がゲートウェイによって読み込まれます。
マルチホームゲートウェイのインスタンスの作成
マルチホームゲートウェイのインスタンスを作成する場合、つまり 1 つの Portal Server 上に複数のゲートウェイを作成する場合は、platform.conf ファイルを次のように変更する必要があります。
gatewaybindipaddress = 0.0.0.0
同じ LDAP を使用するゲートウェイインスタンスの作成
最初のゲートウェイを作成したあとで、同じ LDAP を使用する複数のゲートウェイを作成する場合は、次の操作を行います。
/etc/opt/SUNWam/config/ の AMConfig-instance-name.properties の次の領域を、最初にインストールしたゲートウェイインスタンスと一致するように変更します。
- パスワードの暗号化と復号化に使用される鍵を、最初のゲートウェイに使用されている文字列に置き換えます。
am.encryption.pwd= string_key_specified_in gateway-install
- アプリケーション認証モジュールの共有シークレットである鍵を置き換えます。
com.iplanet.am.service.secret= string_key_specified_in gateway-install
- /etc/opt/SUNWam/config/ums の serverconfig.xml の次の領域を、最初にインストールした Portal Server のインスタンスと一致するように変更します。
<DirDN> cn=puser,ou=DSAME Users,dc=sun,dc=net</DirDN>
<DirPassword>string_key_specified_in gateway-install</DirPassword>
<DirDN>cn=dsameuser,ou=DSAME Users,dc=sun,dc=net</DirDN>
<DirPassword>string_key_specified_in gateway-install </DirPassword>
- amserver サービスを再起動します。
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 -
Linux の場合は次のエントリを追加します。
# mount red.iplanet.com:/misc/export /misc/local
各表記の意味は次のとおりです。
red.iplanet.com は NFS ファイルサーバーのホスト名です。
/misc/export は、red.iplanet.com がエクスポートしているファイルシステムです。
/misc/local は、ローカルマシン上でファイルシステムをマウントする場所です。
注: ローカルマシン上のマウントポイントディレクトリ (上の例では /misc/local) が存在する必要があります。
mount コマンドを実行した後 (および、クライアントが red.iplanet.com NFS サーバーからの適切なアクセス権を持つ場合)、クライアントユーザーはコマンド ls /misc/local を実行することによって、red.iplanet.com 上の /misc/export 内のファイルを一覧表示できます。
- 次のコマンドを入力して、ゲートウェイを再起動します。
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 環境でゲートウェイを再起動するには
ゲートウェイの起動と停止デフォルトでは、ゲートウェイはユーザー noaccess として起動されます。
ゲートウェイを起動するには
- ゲートウェイをインストールし、必要なプロファイルを作成した後、次のコマンドを実行してゲートウェイを起動します。
gateway-install-root/SUNWps/bin/gateway -n default start
default はインストール時に作成されたデフォルトのゲートウェイプロファイルです。独自のプロファイルを後から作成し、その新しいプロファイルでゲートウェイを再起動することができます。「ゲートウェイプロファイルの作成」を参照してください。
ゲートウェイのインスタンスが複数ある場合は、次のコマンドを使用します。
gateway-install-root/SUNWps/bin/gateway start
このコマンドにより、指定されたマシン上に設定されているすべてのゲートウェイインスタンスが起動します。
注
サーバー (ゲートウェイのインスタンスを設定したマシン) を再起動すると、ゲートウェイで設定されたすべてのインスタンスが再起動します。
/etc/opt/SUNWps ディレクトリに古いプロファイルまたはバックアップ用のプロファイルが残っていないことを確認してください。
- 指定されたポートでゲートウェイが稼動しているかどうかを確認する場合は、次のコマンドを実行します。
netstat -a | grep port-number
ゲートウェイのデフォルトのポートは、443 です。
ゲートウェイを停止するには
ゲートウェイの再起動通常はゲートウェイを再起動する必要はありません。再起動が必要なのは、次のいずれかに該当する場合だけです。
別のプロファイルでゲートウェイを再起動するには
ゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n new-gateway-profile-name start
ゲートウェイを再起動するには
端末ウィンドウで root として接続し、次の操作を行います。
ゲートウェイ watchdog を設定するには
watchdog がゲートウェイを監視する間隔を設定することができます。この間隔はデフォルトでは 60 秒に設定されています。これを変更する場合は、crontab ユーティリティーで次の行を編集します。
0-59 * * * * gateway-install-root/SUNWps/bin/
/var/opt/SUNWps/.gw. 5 > /dev/null 2>&1
crontab のエントリを設定する方法については、crontab のマニュアルページを参照してください。
仮想ホストの指定仮想ホストとは、同じマシンの IP とホスト名をポイントする追加のホスト名のことです。たとえば、ホスト名 a.b.c がホスト IP アドレス 192.155.205.133 をポイントしている場合には、同じ IP アドレスをポイントする別のホスト名 c.d.e を追加できます。
仮想ホストを指定するには
- 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-install-root/SUNWps/bin/gateway -n gateway-profile-name start
これらの値を指定しない場合、ゲートウェイは通常どおりに動作します。
Access Manager へアクセスするプロキシの指定ゲートウェイが、Portal Server に配備されている SRA コア (RemoteConfigServlet) にアクセスするために使用するプロキシホストを指定することができます。このプロキシは、Portal Server および Access Manager にアクセスするためにゲートウェイが使用します。
プロキシを指定するには
Web プロキシの使用サードパーティー製の Web プロキシを使用して HTTP リソースにアクセスするように、ゲートウェイを設定することができます。Web プロキシは、クライアントとインターネットの間に設置されます。
Web プロキシの設定
ドメインおよびサブドメインごとに異なるプロキシを使用できます。これらのエントリから、特定のドメインの特定のサブドメインへのアクセスに使用するプロキシがゲートウェイに伝えられます。ゲートウェイで指定したプロキシ設定は次のように機能します。
ドメインとサブドメインのプロキシの設定については、「ドメインとサブドメインのプロキシのリストの作成」を参照してください。
「プロキシを使用する」オプションの設定については、「Web プロキシ使用の有効化」を参照してください。
図 2-1 は、ゲートウェイサービスのプロキシ設定に基づいて Web プロキシ情報が解決される手順を示しています。
図 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 つのエントリがある場合、プロキシ情報のあるエントリが有効なエントリと見なされます。もう 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 を書き換えます。
警告
「ドメインとサブドメインのプロキシ」リストのエントリ * は、書き換えの対象と見なされません。たとえば、表 2-2 の例では、エントリ 24 は書き換えの対象になりません。
リライタについては、第 3 章「プロキシレットとリライタ」を参照してください。
デフォルトのドメインとサブドメイン
URL の最終ホストが完全修飾名になっていない場合、完全修飾名に到達するためにデフォルトのドメインおよびサブドメインが使用されます。
管理コンソールの「デフォルトのドメイン」フィールドに、次のエントリが設定されていると仮定します。
red.sesta.com
上記の例では、sesta.com がデフォルトのドメイン、デフォルトのサブドメインは red です。
URL、host1 が要求された場合、これはデフォルトのドメインとサブドメインを使用して host1.red.sesta.com として解決されます。「ドメインとサブドメインのプロキシ」リストで host1.red.sesta.com が検索されます。
自動プロキシ設定の使用「ドメインとサブドメインのプロキシ」リストの情報を無視するには、自動プロキシ設定機能を有効にします。この設定については、「自動プロキシ設定サポートの有効化」を参照してください。
プロキシ自動設定 (PAC) ファイルを使用するときは、次の点に注意してください。
- ゲートウェイマシンの $JRE_HOME/lib/ext ディレクトリに js.jar が存在する必要があります。このファイルが存在しない場合、ゲートウェイは PAC ファイルをパースできません。
- ゲートウェイは起動時に、ゲートウェイプロファイルの「自動プロキシ設定ファイルの位置」フィールドに指定されている場所から PAC ファイルをフェッチします。場所の設定については、「自動プロキシ設定ファイルの場所の指定」を参照してください。
- ゲートウェイは、URLConnection API を使用してこの場所にアクセスします。ゲートウェイにアクセスするようにプロキシを設定しなければならないときは、プロキシを次のように設定します。
- 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 が返される例
次の「ドメインとサブドメインのプロキシ」を使用する場合を考えます。
対応する 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 へアクセスします。
PAC ファイルの場所の指定
PAC ファイルの場所を指定するための形式は、その場所により次のようになります。
個別のセッションにおけるサービスの追加個別のセッションで Portal Server サービスを追加する場合は、次のことを確認してください。
- すべての Portal Server が、管理コンソールの「ゲートウェイ」 > 「コア」の下に一覧表示されている。詳細については、「Portal Server のリストの作成」を参照してください。
- すべての Portal Server の URL が、「ゲートウェイ」 > 「セキュリティー」の下にある「非認証 URL」に一覧表示されている。詳細については、「非認証 URL のリストの作成」を参照してください。
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 つのポートのみです。1 つのポートは Portal Server への要求を処理し、もう 1 つのポートは 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 gateway 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 プロキシを有効化するときは、Access Manager 管理コンソールの「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 つの利点を次に示します。
リライタプロキシを指定しない場合、いずれかのイントラネットコンピュータにアクセスしようとすると、ゲートウェイコンポーネントによりイントラネットコンピュータに直接つながります。
リライタプロキシを指定しない場合、いずれかのイントラネットコンピュータにアクセスしようとすると、ゲートウェイコンポーネントによりイントラネットコンピュータに直接つながります。リライタプロキシをロードバランサとして使用する場合は、リライタの platform.conf.instance_name がロードバランサ URL をポイントしている必要があります。また、ロードバランサのホストが Portal Servers リストに指定されている必要があります。
リライタプロキシの複数インスタンスをゲートウェイの各インスタンスに割り当てる場合 (Portal Server ノード上でなくてもかまわない) には、platform.conf ファイルで、リライタプロキシに対して 1 つのポートエントリを入力するのではなく、host-name:port の形式でリライタプロキシごとに詳細を入力します。
リライタプロキシのインスタンスの作成
リライタプロキシの新しいインスタンスを 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 gateway 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 は必要なゲートウェイインスタンスのプロファイル名です。
リライタプロキシの有効化
リライタプロキシを有効化するときは、Access Manager 管理コンソールの「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() を使用します。次の表は、HTTP ヘッダー内の情報を示しています。
表 2-3 HTTP ヘッダー内の情報
ヘッダー
構文
説明
PS-GW-PDC
X-PS-GW- PDC: true/false
ゲートウェイで PDC が有効であるかどうかを示します。
PS-Netlet
X-PS-Netlet:enabled=true/false
ゲートウェイで Netlet が有効化されているか、それとも無効化されているかを示します。
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
X-PS-GW-URL: http(s)://gatewayURL(:port)
クライアントが接続している URL を示します。
ポートが標準ポートでない場合 (つまり、80/443 以外のポートでゲートウェイが HTTP/HTTPS モードで稼動している場合) は、「:port」が追加されます。
PS-GW-Rewriting-URL
X-PS-GW-URL: http(s)://gatewayURL(:port)/[SessionInfo]
ゲートウェイがすべてのページを書き換える URL を示します。
注: 認証ページからの応答のように、応答の過程でユーザーの Access Manager のセッション ID が変更された場合、ページは、それまでヘッダーに指定されていた値ではなくその値で書き換えられます。
例
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/
PS-GW-Rewriting-URL: https://siroe.india.sun.com:10443/SessIDValCustomEncodedValue/
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 インスタンスに認証モジュールを追加するには
- Access Manager 管理コンソールに管理者としてログインします。
- 適切な組織を選択します。
- 「表示」ドロップダウンメニューから「サービス」を選択します。
左の区画にサービスが表示されます。
- 「認証設定」の隣の矢印をクリックします。
「サービスインスタンスリスト」が表示されます。
- gatewaypdc をクリックします。
「gatewaypdc プロパティーを表示」ページが表示されます。
- 「認証設定」の「編集」のリンクをクリックします。
「モジュールの追加」が表示されます。
- 「モジュール名」を選択し、「適用基準」を「必修」に設定します。オプションは空白のまま残せます。
- 「了解」をクリックします。
- 1 つまたは複数のモジュールを追加したら、「保存」をクリックします。
- 「gatewaypdc プロパティーの表示」ページをクリックします。
- 変更を有効にするために、ゲートウェイを再起動します。
gateway-install-root/SUNWps/bin/gateway -n gateway-profile-name start
ワイルドカード証明書の使用ワイルドカード証明書は、ホストの完全修飾 DNS 名にワイルドカード文字を含む単一の証明書を受け付けます。
これによって、同じドメイン内で証明書が複数のホストを保証することが可能になります。たとえば、*.domain.com の証明書は abc.domain.com と abc1.domain.com に使用できます。実際には、この証明書は domain.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
ゲートウェイサービスのユーザーインタフェースのカスタマイズここでは、編集可能な各種のプロパティーファイルについて説明します。
srapGateway.properties ファイル
このファイルは、次の目的のために編集できます。
srapgwadminmsg.properties ファイル
このファイルは、次の目的のために編集できます。
LDAP ディレクトリの共有Portal Server と Access Manager サーバーの 2 つのインスタンスが同じ LDAP ディレクトリを共有している場合は、それ以後の Portal Server、Access Manager、およびゲートウェイに対してはこの回避策を使用してください。
- AMConfig.properties の次の領域を変更して、最初にインストールした Portal Server および Access Manager サーバーのインスタンスと同期するようにします。
#The key that will be used to encrypt and decrypt passwords. am.encryption.pwd=t/vnY9Uqjf12NbFywKuAaaHibwlDFNLO <== この文字列を最初のポータルのインストールの文字列に置き換えます
/* The following key is the shared secret for application auth module */ com.iplanet.am.service.secret=AQICxIPLNc0WWQRVlYZN0PnKgyvq3gTU8JA9 <== この文字列を最初のポータルのインストールの文字列に置き換えます
- /etc/opt/SUNWam/config/ums にある serverconfig.xml の次の領域を変更して、最初にインストールした Portal Server および Access Manager サーバーのインスタンスと同期するようにします。
<DirDN>
cn=puser,ou=DSAME Users,dc=sun,dc=net
</DirDN>
<DirPassword>
AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY <== この文字列を最初のポー タルのインストールの文字列に置き換えます
</DirPassword>
<DirDN>
cn=dsameuser,ou=DSAME Users,dc=sun,dc=net
</DirDN>
<DirPassword>
AQICxIPLNc0WWQT22gQnGgnCp9rUf+FuaqpY <== この文字列を最初の ポータルのインストールの文字列に置き換えます
</DirPassword>
- amserver サービスを再起動します。
連携管理の使用連携管理により、ユーザーが 1 つのネットワーク ID を持つように、ユーザーはユーザーのローカル ID を収集できます。連携管理ではネットワーク ID を使用して、ユーザーによる 1 つのサービスプロバイダサイトへのログインを許可し、ID を再認証することなく、他のサービスプロバイダサイトへのアクセスを許可します。これをシングルサインオンと呼びます。
Portal Server では、連携管理をオープンモードとセキュアモードに設定できます。連携管理をオープンモードに設定する方法については、『Portal Server 管理ガイド』を参照してください。Secure Remote Access を使用して連携管理を設定する前に、これがオープンモードで機能することを確認します。ユーザーが同じブラウザで連携管理をオープンモードとセキュアモードの両方で使用できるようにするには、ブラウザから Cookie とキャッシュをクリアする必要があります。
連携管理の詳細については、『Access Manager Federation Management 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 の複数のインスタンスで有効です。
- Access Manager 管理コンソールに管理者としてログインします。
- 管理コンソールの「サービス設定」タブを選択します。
- 「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 の複数のインスタンスで有効です。
- Access Manager 管理コンソールに管理者としてログインします。
- 管理コンソールの「サービス設定」タブを選択します。
- 「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 プロバイダはファイアウォールによって保護されたサブネットに常駐し、サービスプロバイダには企業ネットワーク内から直接アクセスできます。
- Access Manager 管理コンソールに管理者としてログインします。
- 管理コンソールの「サービス設定」タブを選択します。
- 「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
